blakeslee-research/nucleic-purpose-classifier
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updating purpose-classifier data:

Browse Source
This commit is contained in:
abkslm
2026-08-02 20:15:13 -07:00
parent 98311aa932
commit 0f639bfa05
21 changed files with 14248 additions and 14463 deletions
Download Patch File Download Diff File Expand all files Collapse all files
data/round2-06.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "payroll run 2026-07 blew up halfway through and left 400 employees unpaid:\n\norg.springframework.dao.DeadlockLoserDataAccessException: PreparedStatementCallback; SQL [update payslip set net_cents=?, status=? where id=?]; Deadlock found when trying to get lock; try restarting transaction\n\tat org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:263)\n\tat io.paycrest.payroll.PayslipRepository.updateNet(PayslipRepository.java:141)\n\tat io.paycrest.payroll.RunProcessor.processEmployee(RunProcessor.java:212)\n\tat io.paycrest.payroll.RunProcessor.lambda$run$3(RunProcessor.java:88)\n\tat java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)\nCaused by: java.sql.SQLTransactionRollbackException: Deadlock found when trying to get lock\n\nrun 88412, 1,204 employees, parallel stream over the employee list, 8 threads", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer falls behind head every few hours and never catches up without a restart:\n\n2026-07-29T11:02:14Z INFO indexer: processing block 21,104,882 (lag 2 blocks)\n2026-07-29T11:04:02Z INFO indexer: processing block 21,104,918 (lag 41 blocks)\n2026-07-29T11:08:11Z WARN indexer: rpc request took 8.4s method=eth_getLogs range=1000\n2026-07-29T11:08:19Z WARN indexer: rpc request took 11.2s method=eth_getLogs range=1000\n2026-07-29T11:12:44Z WARN indexer: reorg detected at 21,104,801, rolling back 12 blocks\n2026-07-29T11:12:58Z INFO indexer: reprocessing from 21,104,789 (lag 214 blocks)\n2026-07-29T11:31:02Z WARN indexer: postgres connection pool exhausted (20/20), waiting\n2026-07-29T11:44:18Z INFO indexer: processing block 21,104,912 (lag 604 blocks)\n\nthe RPC provider says our request rate is well within limits", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "our safety concept document has to go to the auditor in november, and writing it will expose where our latency budget doesn't close. produce the document, and give me a separate honest list of the numbers that don't add up so we can decide what to fix first", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "the payroll module ignores half our design tokens and its warning colour fails contrast on the row background it's used with. bring it onto the tokens, fix the contrast, and note in the design system docs which token pairs are safe on which surfaces there are fourteen hardcoded colours in there, six of them near-misses of a real token.", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "angular app throws this on the timesheet screen for about one user in fifty:\n\nERROR RangeError: Maximum call stack size exceeded\n at Object.eval [as updateDirectives] (TimesheetGridComponent.html:41:9)\n at Module.debugUpdateDirectives (core.mjs:44112:12)\n at checkAndUpdateView (core.mjs:41882:5)\n at callViewAction (core.mjs:42214:21)\nERROR Error: NG0100: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value for 'ngClass': 'row-warning'. Current value: 'row-error'.\n at throwErrorIfNoChangesMode (core.mjs:12044:11)\n\nthe grid has a getter in the template that computes the row state from the entries, and users with more than about 200 entries in a week hit it", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer pool size up to 40", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "payroll thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "our angular app pulls fontawesome and moment into the initial bundle for three date formats and four icons, which is most of the budget overrun. replace both, keep the rendering identical, and check the print stylesheet still works", "purpose": "quickFix", "secondary": "refactor", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt": "the payroll run has no alert when it sits in RUNNING for more than an hour, which is how we found out at breakfast", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "robot stops mid-path maybe once a day, and this is what the diagnostics dump:\n\nros2 topic hz /scan\n average rate: 9.412 min: 0.104s max: 0.882s std dev: 0.14112s window: 50\nros2 topic hz /odom\n average rate: 49.881 min: 0.019s max: 0.021s std dev: 0.00041s window: 50\n\n[nav2_controller]: Control loop missed its desired rate of 20.0000Hz... the loop actually took 0.2841 seconds\n[nav2_controller]: Invalid path, Path is empty.\n[behavior_server]: Running backup\n[bt_navigator]: Behavior tree threw exception: Action server timed out\n\nthe lidar is meant to publish at 10Hz and the CPU on the nav box sits at 60%", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "payslip PDF still says 2025 tax year", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "a spanish customer signs in september and we support four countries, none of them spain, which means social security bands, a different absence model and a filing format we've never produced. before anyone opens the calculator i want a plan: what a country pack actually has to contain, how much of spain is data versus code, and whether we can get there without touching the other four countries' behaviour at all", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "we owe a customer a written explanation for why four hundred people were paid late, and their HR director's actual question is why we didn't know until the morning. write the incident report: what happened, what the impact was, why our monitoring missed it, and what changes — without hiding behind the word \"deadlock\"", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "angular component behind our slowest screen. is the getter the whole problem or just part of it?\n\n@Component({\n selector: 'timesheet-grid',\n template: `\n <tr *ngFor=\"let row of rows\" [ngClass]=\"rowState(row)\">\n <td *ngFor=\"let day of row.days\">{{ formatHours(day) }}</td>\n <td>{{ totalFor(row) }}</td>\n </tr>`\n})\nexport class TimesheetGridComponent {\n @Input() entries: Entry[] = []\n get rows() { return this.groupByEmployee(this.entries) }\n rowState(r: Row) { return r.days.some(d => this.hasConflict(d)) ? 'row-error' : 'row-warning' }\n totalFor(r: Row) { return r.days.reduce((a, d) => a + this.minutes(d), 0) / 60 }\n hasConflict(d: Day) { return this.entries.filter(e => e.day === d.date).length > 1 }\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "before this goes anywhere near a payroll run, tell me what's wrong with it:\n\n@Transactional\npublic void run(UUID runId) {\n PayrollRun run = runs.findById(runId).orElseThrow();\n run.getEmployees().parallelStream().forEach(emp -> {\n Payslip slip = calculator.calculate(emp, run.getPeriod());\n payslips.save(slip);\n run.addTotal(slip.getNetCents());\n });\n run.setStatus(COMPLETED);\n runs.save(run);\n events.publish(new PayrollCompleted(runId, run.getTotalCents()));\n}\n\nrun.addTotal mutates a long field on the entity; calculator hits the database for tax bands per employee", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "three services in the ROS graph each do their own transform lookup, with their own error handling:\n\n// pick_place_node.cpp\ntry { tf_buffer_->lookupTransform(\"base_link\", \"tool0\", tf2::TimePointZero); }\ncatch (const tf2::TransformException& e) { RCLCPP_WARN(get_logger(), \"%s\", e.what()); return; }\n\n// perception_node.cpp\nauto tf = tf_buffer_->lookupTransform(\"base_link\", \"camera_link\", msg->header.stamp,\n tf2::durationFromSec(0.1)); // throws on timeout\n\n// safety_node.cpp\nif (!tf_buffer_->canTransform(\"base_link\", \"lidar\", tf2::TimePointZero)) { return last_known_; }\n\none returns stale data on failure, one drops the message, one throws into a callback", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "absence type dropdown is missing bereavement", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "one date-range validator for all controllers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "what happens when a tax table is missing?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "is `IsSafe` thread-safe as written?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "robot cell has to pass certification in november and our own numbers don't obviously add up — the perception pipeline alone measures 180ms against a 250ms budget, and the safety check shares a process with the motion controller. work through what the architecture would need to look like to actually satisfy the requirement, and what evidence we'd have to produce alongside it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "payslip generation, PDF rendering and the bank file writer all live in one class called `PayrollService`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a walkthrough of how an absence becomes a deduction line would help before i touch the calculator", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "we need bank file generation to be resumable, because a 40MB export currently regenerates from scratch on every poll", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "arm drifts a few centimetres over a shift and we recalibrate every morning as a workaround:\n\n[ INFO] [1753843201.114]: joint_state_publisher: publishing at 50Hz\n[ WARN] [1753843261.882]: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 1753843261.880\n[ WARN] [1753843262.114]: TF_REPEATED_DATA ignoring data with redundant timestamp for frame tool0 at time 1753843262.112\n[ WARN] [1753843321.441]: Lookup would require extrapolation into the past. Requested time 1753843321.401 but the earliest data is at time 1753843321.412\n[ERROR] [1753843382.002]: Trajectory execution aborted: goal tolerance violated on joint_4 (0.0142 > 0.0100)\n[ INFO] [1753843382.114]: controller reset, resuming\n\nsim is perfect, and it only happens on the two cells with the newer controllers", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "webhooks to our customers' HR systems started failing on tuesday, only for two of them:\n\nPOST https://hr.customer-a.example/webhooks/paycrest\n → 200 OK in 412ms\n\nPOST https://api.customer-b.example/paycrest\n → SSL routines:ssl3_read_bytes:sslv3 alert handshake failure\n → retry 1: same\n → retry 2: same\n → giving up after 3 attempts, event queued\n\nPOST https://hooks.customer-c.example/in\n → 421 Misdirected Request\n → retry 1: 421\n → giving up\n\nwe upgraded the base image on monday, from debian bookworm to trixie", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "reorg handling, which i inherited and don't trust:\n\nasync fn handle_block(&mut self, block: Block) -> Result<()> {\n let parent = self.db.get_block(block.number - 1).await?;\n if parent.hash != block.parent_hash {\n let depth = self.find_common_ancestor(&block).await?;\n self.db.delete_blocks_from(depth + 1).await?;\n self.cursor = depth;\n return Ok(());\n }\n let logs = self.rpc.get_logs(block.number, block.number).await?;\n let mut tx = self.db.begin().await?;\n self.db.insert_block(&mut tx, &block).await?;\n for log in logs { self.apply_log(&mut tx, log).await?; }\n tx.commit().await?;\n self.cursor = block.number;\n Ok(())\n}\n\nfind_common_ancestor walks back one block at a time; delete_blocks_from cascades to the balances table", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "this is the safety check on our motion controller and i want another pair of eyes before the certification audit:\n\nbool MotionController::IsSafe(const State& s) const {\n if (estop_pressed_.load()) return false;\n if (s.velocity.norm() > max_velocity_) return false;\n if (last_heartbeat_age() > std::chrono::milliseconds(250)) return false;\n for (const auto& obstacle : obstacles_) {\n if ((s.position - obstacle.position).norm() < safety_radius_) return false;\n }\n return true;\n}\n\nobstacles_ is refreshed by the perception callback on another thread; last_heartbeat_age reads a member updated in the same callback; there is no mutex anywhere in this class", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "RFC for our new payout scheduling. does the reasoning survive contact with reality?\n\n## Proposal\nMove payroll runs from a single nightly batch to a queue of per-employee jobs. Each job is independently retryable, and a run completes when every job reports success.\n\n## Rationale\nA single failing employee currently fails the whole run, and we cannot restart from the middle.\n\n## Consequences\n- Partial runs become visible to customers, who will ask what \"partially paid\" means.\n- Totals can no longer be computed in the same transaction as the slips.\n- Retry storms are possible if the tax service is down.\n\n## Open\nWhether a run can be approved before all jobs complete.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "safety documentation for the cell, which the auditor will read line by line. what we have:\n\n- e-stop cuts power to the servo drives directly, software is not in the loop\n- the software safety check runs at 100Hz and stops motion if the heartbeat is older than 250ms\n- obstacle detection comes from two lidars, fused, with a 200mm safety radius around the tool\n- reduced-speed mode is entered when a human is detected in the cell, at 250mm/s\n- the perception pipeline has a measured worst-case latency of 180ms\n- recovery from a safety stop requires a physical reset, not a software command\n\nwrite the safety concept document; where our numbers don't add up against a 250ms budget, say so rather than smoothing it over", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the indexer, from the commits since v0.9:\n\n41c9e0b feat(reorg): handle reorgs deeper than 12 blocks\n88f21c0 fix(logs): decode indexed value parameters on Transfer\nc0aa774 perf(rpc): batch eth_getLogs into 200-block ranges\n2e91b45 fix(db): don't hold a transaction across an RPC call\naa30f19 feat(api): expose /v1/balances/{address} with block-height parameter\n9c1d004 chore: bump alloy to 0.8\n4410bb7 fix(cursor): persist the cursor after commit, not before\nb77e910 feat(metrics): per-contract indexing lag\n\nour users are other teams who run this themselves; two of these change behaviour in ways that need explaining", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "support keeps getting asked this and answering differently each time. from the code, write the definitive page:\n\ncustomer question: \"When exactly does an absence affect pay? We entered sick leave on the 28th for the period that closed on the 25th, and the employee was paid in full, then a correction appeared the following month with no explanation on the payslip.\"\n\nwhat the code does: absences in a closed period are accepted with retro=true; the next run generates a correction line; the correction line's description is the absence type only, with no dates; the payslip PDF renders corrections in a separate block at the bottom; and if the employee leaves before the next run, the correction is silently dropped", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "same date-range validation lives in four controllers with four different error messages:\n\n// AbsenceController\nif (req.getEnd().isBefore(req.getStart())) throw new BadRequest(\"end before start\");\n\n// TimesheetController\nif (!req.getEnd().isAfter(req.getStart())) throw new BadRequest(\"invalid range\");\n\n// ReportController\nif (req.getStart().plusYears(1).isBefore(req.getEnd())) throw new BadRequest(\"range too wide\");\nif (req.getEnd().isBefore(req.getStart())) throw new BadRequest(\"end before start\");\n\n// PayrollController\nAssert.isTrue(req.getStart().compareTo(req.getEnd()) <= 0, \"bad range\");\n\nthe API contract says a range where start equals end is valid, and two of these disagree", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer's event decoding is a match arm per contract and there are now 40 of them:\n\nmatch (log.address, log.topics[0]) {\n (addr, topic) if addr == USDC && topic == TRANSFER => decode_transfer_indexed(log),\n (addr, topic) if addr == DAI && topic == TRANSFER => decode_transfer(log),\n (addr, topic) if addr == WETH && topic == TRANSFER => decode_transfer(log),\n (addr, topic) if addr == USDC && topic == APPROVAL => decode_approval(log),\n // ... 36 more\n _ => Ok(None),\n}\n\nadding a token means editing this match, and half the arms differ only in whether the value parameter is indexed", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the timesheet week view, angular, replacing the grid that falls over:\n\nWeek view (desktop, 1280px+)\n- Employee rows, sticky first column with name and role, 7 day columns plus a total column.\n- Cells show hours as a decimal to one place; empty cells show an em dash at 40% opacity.\n- Conflicts (two entries on the same day) render an amber left border on the cell and a tooltip listing both.\n- Cells are editable inline: click focuses an input, enter commits and moves down, escape reverts, tab moves right.\n- Unsaved edits show a small dot in the corner; a failed save turns the cell's border destructive with a retry affordance.\n- The total column recalculates optimistically as you type.\n- Above 500 rows the table virtualises, but the sticky column and the totals must stay correct while scrolling.\n- Keyboard-only operation must be possible for the whole grid, including conflict resolution.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "run progress bar needs an elapsed timer", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "why does startup take four minutes?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "whatever the auditor needs", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "timesheet screen is the top support complaint and the obvious fix is virtualising the grid, but i suspect the real problem is that the component recomputes everything in template getters. before committing to a rewrite i want a view on whether this is a restructure of the existing component or a genuine redesign, and what each would cost", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether our motion controller's safety check is actually safe, because the obstacle list and the heartbeat are written by a perception callback on another thread and there isn't a mutex in the class. read it properly and tell me what can go wrong, how likely it is, and whether the certification auditor would accept it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "employee portal fails most of an accessibility audit and our public sector customers will ask about it at renewal. fix the concrete items — the payslip iframe, the calendar keyboard navigation, form error association — and write the accessibility statement we can publish afterwards the statement has to be specific enough that a procurement reviewer can check it.", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "i want a position on whether the robot's perception and safety should share a computer at all", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "one tf lookup helper for the three nodes", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "three more chains are on the indexer's roadmap and each one is a week of work plus permanent RPC cost, while the existing chain already falls behind after every reorg. i'd rather we agreed what \"supporting a chain\" means for us — backfill, lag SLOs, cost per chain — before saying yes to any of them, and then decided which of the three is actually worth doing first", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "before we build spanish payroll i want the country-pack boundary agreed — what's data, what's code, how tax years are versioned — and then the boundary proven by moving one existing country onto it, ideally the simplest one, so we find out what's wrong with the design before spain lands", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "is the reporting query's correlated subquery the reason it times out, or is it the left join on payslips", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does the export endpoint make when two of the customer's servers poll it at once", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "absence approval endpoint should reject approvals from someone in the requester's own reporting line", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "les cotisations sociales sont fausses pour trois salariés et je ne vois pas pourquoi :\n\nSalarié 4412 brut 3 200,00 plafond SS 3 864,00 tranche A 3 200,00 tranche B 0,00 ✓\nSalarié 4418 brut 4 100,00 plafond SS 3 864,00 tranche A 3 864,00 tranche B 236,00 ✓\nSalarié 4421 brut 4 100,00 plafond SS 3 864,00 tranche A 4 100,00 tranche B 0,00 ✗\nSalarié 4429 brut 5 000,00 plafond SS 3 864,00 tranche A 3 864,00 tranche B 1 136,00 ✓\nSalarié 4433 brut 4 100,00 plafond SS 3 864,00 tranche A 4 100,00 tranche B 0,00 ✗\n\nles trois salariés en erreur ont tous eu un avenant au contrat en cours de mois, et le plafond devrait être proratisé", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "fr"}
{"prompt": "balances in the indexer disagree with the chain for exactly four addresses:\n\naddress indexed on-chain diff\n0x8f21c0aa774119a2b3c4d5e6f7a8b9c0d1e2f3a4 1,204.118401 1,204.118401 0\n0x41ba190c0aa7741192b3c4d5e6f7a8b9c0d1e2f3 882.441000 882.437600 0.0034\n0x2e91b45aa30f199c1d0044410bb7b77e91030cc2 0.000000 12.400000 12.4\n0xc0aa7741ba190882e91b452e91b45aa30f199c1d 4,118.220000 4,118.220000 0\n0xaa30f199c1d0044410bb7b77e91030cc219e1f0a 41.000000 40.999999 0.000001\n\nreconciliation job output:\n checked 41,882 addresses across 12 tokens\n mismatches: 4 (all on token 0x9c1d0044410bb7b77e91030cc219e1f0a8f21c0a)\n first divergence at block 21,041,882\n last full agreement at block 21,041,881\n\nthe token's ABI:\n event Transfer(address indexed from, address indexed to, uint256 indexed value)\n\nevery other token we index declares value as a non-indexed parameter, and all four addresses received from this contract", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "payroll engine migration has two months of parallel running left and has to finish before year end, but the diff process is a gist, the sign-off is an email, and nobody has defined what a clean month looks like. i'd like the remaining migration planned properly, including the cutover criteria, what we do if month four fails, and how we prove to an auditor afterwards that the numbers matched", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "indexer decodes events through a forty-arm match on address and topic, where most arms differ only in whether the value parameter is indexed, and adding a token means editing it. replace it with a registry that's data rather than code, keeping the decoding behaviour byte-identical for every contract we currently index", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "our javadoc claims the run is atomic, which stopped being true when we parallelised it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "the payroll run has no alert while it sits in RUNNING, which is why a failure at two in the morning was found at six by a human. add the alerting, and tell me what else in that pipeline has the same shape — a state that can be entered and never left without anyone noticing", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "angular build warnings that have been ignored for a year and now break the budget:\n\nWarning: bundle initial exceeded maximum budget. Budget 1.00 MB was not met by 412.11 kB with a total of 1.40 MB.\nWarning: src/app/timesheet/timesheet-grid.component.ts depends on 'moment'. CommonJS or AMD dependencies can cause optimization bailouts.\nWarning: src/app/shared/icons.ts depends on '@fortawesome/fontawesome-free'. CommonJS or AMD dependencies can cause optimization bailouts.\nWarning: src/app/payroll/payroll.module.ts is part of the declarations of 2 modules\n\nError: Budget exceeded, build failed\n\nmoment is used in three files for date formatting only", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer needs a story for backfilling a single contract after a decoding bug, without reindexing everything or touching other contracts' data. think it through with me — cursor per contract, ranges, how balances get recomputed — then implement the range-reprocessing command ranges have to be resumable, because one contract's history is months of blocks.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "payroll calculator is one class with a branch per country, two hundred lines each, and the proposal on the table is a rules engine with country packs loaded at runtime. i can see why, and i can also see auditors asking which rules produced a payslip three years ago. weigh the options honestly, including the boring one where it stays code but gets restructured", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "our health endpoint reports the indexer healthy while it's six hundred blocks behind head", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "the `dual_write` flag governs the whole payroll migration and nobody can say precisely what it switches any more. work out what it actually does from the code, then write the page describing it, including what happens if someone turns it off halfway through a run", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "robot cell repo has a two-line readme and a twenty-minute manual calibration procedure documented in a scanned pdf. write the readme a new engineer could actually follow to a moving robot, including the vendored driver patch, the realtime kernel requirement, and the launch-order problem that bites everyone on hardware assume the reader has used ROS before but has never seen this cell.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "payslip viewer should let people download the PDF without opening the iframe at all", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "a short note for the team on why balances are becoming a sum over deltas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "we need to decide whether the timesheet week view keeps its own state or moves to the store the rest of the app uses", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "angular modules call the API three different ways depending on which year they were written, three components forget to unsubscribe, and only one handles the error case. bring all fourteen onto the newest pattern, keep every screen behaving as it does now, and make the error handling consistent rather than absent fourteen components in total, and the newest pattern is the one we want to end up on.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "spring boot app takes 4 minutes to start in prod and 20 seconds locally:\n\n2026-07-29T11:02:14.881Z INFO 1 --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)\n2026-07-29T11:02:18.114Z INFO 1 --- [main] o.h.jpa.internal.util.LogHelper : HHH000204: Processing PersistenceUnitInfo [name: default]\n2026-07-29T11:04:41.882Z INFO 1 --- [main] o.h.e.j.e.i.LobCreatorBuilderImpl : HHH000424: Disabling contextual LOB creation as createClob() method threw error\n2026-07-29T11:05:52.114Z INFO 1 --- [main] o.s.o.j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'\n2026-07-29T11:06:02.441Z INFO 1 --- [main] i.p.config.TaxTableLoader : loaded 41,882 tax bands\n2026-07-29T11:06:14.002Z INFO 1 --- [main] i.paycrest.Application : Started Application in 241.118 seconds\n\nthe gap between 11:02:18 and 11:04:41 is where it sits doing nothing visible", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "gazebo sim passes, real robot fails the same test, and the only difference i can find is timing:\n\n[component_container]: Failed to load component: Package 'gripper_driver' not found\n[component_container]: Component loaded: force_sensor_node\n[force_sensor_node]: Publishing /wrench at 500Hz\n[gripper_action_server]: Waiting for /wrench...\n[gripper_action_server]: Waiting for /wrench...\n[gripper_action_server]: Timed out waiting for /wrench after 5.0s\n[pick_place_node]: Aborting: gripper action server unavailable\n[pick_place_node]: Retrying (1/3)\n[gripper_action_server]: Received first /wrench message\n\nthe force sensor node comes up about 6 seconds after the gripper server on hardware, instantly in sim", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "der Kollege hat das für die Lohnabrechnung geschrieben, bitte einmal drüberschauen:\n\npublic BigDecimal berechneSteuer(BigDecimal brutto, Steuerklasse klasse, int jahr) {\n var tabelle = tabellen.get(jahr);\n if (tabelle == null) {\n tabelle = tabellen.get(jahr - 1); // Fallback auf das Vorjahr\n }\n var band = tabelle.stream()\n .filter(b -> brutto.compareTo(b.von()) >= 0 && brutto.compareTo(b.bis()) <= 0)\n .findFirst()\n .orElse(tabelle.get(tabelle.size() - 1));\n return brutto.multiply(band.satz()).setScale(2, RoundingMode.HALF_UP);\n}\n\ndie Tabellen für 2026 sind noch nicht eingepflegt, und die Klasse wird nirgends verwendet", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "sql the reporting screen runs, which times out for our biggest customer:\n\nSELECT e.id, e.full_name, d.name AS department,\n SUM(p.gross_cents) AS ytd_gross,\n SUM(p.tax_cents) AS ytd_tax,\n (SELECT COUNT(*) FROM absences a WHERE a.employee_id = e.id AND a.starts_at >= $2) AS absence_count,\n (SELECT MAX(pr.paid_at) FROM payslips pr WHERE pr.employee_id = e.id) AS last_paid\nFROM employees e\nJOIN departments d ON d.id = e.department_id\nLEFT JOIN payslips p ON p.employee_id = e.id AND p.period >= $2\nWHERE e.org_id = $1 AND e.terminated_at IS NULL\nGROUP BY e.id, e.full_name, d.name\nORDER BY e.full_name;\n\n41,000 employees, payslips has 4.1M rows, and there's an index on payslips(employee_id, period)", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ROS launch file, which nobody wants to touch. what does it actually guarantee about startup order?\n\ndef generate_launch_description():\n return LaunchDescription([\n Node(package='lidar_driver', executable='lidar_node', output='screen'),\n Node(package='force_sensor', executable='force_node', output='screen'),\n Node(package='gripper_driver', executable='gripper_action_server', output='screen'),\n TimerAction(period=5.0, actions=[\n Node(package='nav2_bringup', executable='navigation_launch', output='screen'),\n ]),\n Node(package='pick_place', executable='pick_place_node', output='screen',\n parameters=[{'wrench_timeout': 5.0}]),\n ])\n\non hardware the force sensor takes about six seconds to enumerate over USB", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "payroll's parallel-run notes from the migration, they need to become a proper runbook:\n\n- we run the old and new engines on the same period and diff the payslips\n- differences under 2 cents are ignored, anything above goes in a spreadsheet\n- the diff script lives in a gist, takes a run id, and needs read access to both databases\n- known acceptable differences: rounding on pension contributions, and the order of deduction lines\n- if more than 5 employees differ we don't cut over that month\n- the finance lead signs off by replying to an email, which is our only record\n- we've done this for three months and have two months to go", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "public API for absences, documented by nobody. this is what the controller does:\n\n@PostMapping(\"/v2/absences\")\npublic AbsenceDto create(@RequestBody @Valid AbsenceRequest req, @AuthenticationPrincipal Principal p) {\n // employee must belong to the caller's org, else 404 (deliberately not 403)\n // overlapping absences of the same type are rejected with 409\n // overlapping absences of different types are allowed and both count\n // half days are expressed as 0.5 in `days`, quarter days are not supported\n // absences in a closed payroll period are accepted but flagged `retro: true`\n // a retro absence triggers a correction on the next run, never a rerun\n // the `approver_id` is ignored on create and set by the approval endpoint\n}\n\nwrite the reference page, and be explicit about the 404-instead-of-403 because integrators keep filing bugs about it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from the failed payroll run, and 400 people were paid late. we owe the customer a write-up:\n\n02:14 run 88412 starts, 1,204 employees\n02:31 run fails with a database deadlock, status stuck at RUNNING\n02:33 automatic retry starts, fails identically\n06:02 on-call notices during the morning check, not from an alert\n06:40 we establish 804 payslips were written and 400 were not\n07:15 decision: complete the run manually rather than restart it\n09:52 remaining 400 payslips generated, bank file submitted\n11:30 bank confirms the second file, employees paid same day but late\n14:00 root cause: parallel processing of employees updating a shared run total row\n\nthe customer's HR director wants to know why we didn't know until the morning", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "escribe la guía de despliegue a partir de estas notas, que hoy están en la cabeza de una persona:\n\n- el indexador se despliega con helm, pero antes hay que parar el reorg handler manualmente\n- si no se para, la migración de la tabla `blocks` se bloquea y hay que matar la conexión a mano\n- las migraciones se aplican con `sqlx migrate run` desde un pod temporal, no en el arranque\n- después del despliegue hay que verificar que el cursor avanza; si no avanza en dos minutos, rollback\n- el rollback es volver al chart anterior y reiniciar desde el último checkpoint, se pierden unos 10 minutos de datos\n- nunca desplegar durante una reorganización en curso, se corrompen los saldos\n- hay un feature flag `dual_write` que debe estar activo durante toda la migración", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "es"}
{"prompt": "README for the robot cell repo, currently two lines. what a new person needs:\n\n- ROS 2 Jazzy, ubuntu 24.04, colcon workspace, three packages plus a vendored driver\n- the vendored gripper driver has a patch on top of upstream that must be reapplied after any update, patch is in patches/\n- simulation: `ros2 launch cell_bringup sim.launch.py`, works on any machine\n- hardware: needs the realtime kernel, the user in the dialout group, and the safety PLC in maintenance mode\n- the calibration procedure is a 20 minute manual process documented in a pdf someone scanned\n- tests: unit tests run anywhere, integration tests need either sim or hardware and are not in CI\n- known issue: the force sensor enumerates slowly on hardware, which breaks the launch order\n\nwrite the readme so someone can get to a moving robot without a tap on the shoulder", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "o texto do email que vai para 1.400 empregados está mau, reescreve-o:\n\n\"Caro colaborador, Informamos que devido a uma incidência técnica no processamento do vencimento referente ao mês de Julho, o pagamento poderá ter sido efetuado com atraso relativamente à data habitual. A situação encontra-se resolvida. Agradecemos a compreensão. Departamento de Recursos Humanos.\"\n\nfactos: o pagamento chegou no mesmo dia mas várias horas mais tarde; não houve erro nos valores; ninguém precisa de fazer nada; quem tenha tido encargos bancários por causa do atraso deve contactar o RH e será reembolsado", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "pt"}
{"prompt": "checkstyle and spotbugs after the merge, and the build gate goes on next week:\n\n[ERROR] PayslipRepository.java:141: Method length is 88 lines (max allowed is 50). [MethodLength]\n[ERROR] RunProcessor.java:88: 'if' construct must use '{}'s. [NeedBraces]\n[WARNING] TaxTableLoader.java:22: Found reliance on default encoding: new FileReader(String) [DM_DEFAULT_ENCODING]\n[WARNING] AbsenceService.java:66: Possible null pointer dereference of approver in AbsenceService.approve() [NP_NULL_ON_SOME_PATH]\n[WARNING] Money.java:41: Class defines equals() but not hashCode() [HE_EQUALS_USE_HASHCODE]\n\n2 errors, 3 warnings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "clippy on the indexer, some of these look like they matter:\n\nwarning: this `.await` holds a non-Send type across an await point\n --> src/indexer/handler.rs:88:9\nwarning: large enum variant\n --> src/types.rs:41:1\n |\n41 | enum Event { Transfer(TransferEvent), Approval(Box<ApprovalEvent>), Raw([u8; 4096]) }\nwarning: this loop never actually loops\n --> src/rpc/retry.rs:22:5\nwarning: called `unwrap` on a `Result` value in an async fn\n --> src/db/cursor.rs:141:32\n\nwarning: `indexer` (bin \"indexer\") generated 18 warnings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "connection pool settings across our services, and the indexer is the one that exhausts:\n\n# api\nspring.datasource.hikari.maximum-pool-size: 40\nspring.datasource.hikari.connection-timeout: 30000\n\n# worker\nspring.datasource.hikari.maximum-pool-size: 20\nspring.datasource.hikari.connection-timeout: 30000\n\n# indexer (rust, sqlx)\nmax_connections: 20\nacquire_timeout: 30s\nidle_timeout: 600s\n\n# postgres\nmax_connections = 100\nreserved_connections = 3\n\nthe indexer opens a transaction per block and holds it across the RPC call for logs", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "docker base image bump broke outbound TLS to two customers, here's the difference:\n\n# before (bookworm)\nopenssl version: OpenSSL 3.0.11\nMinProtocol = TLSv1.2\nCipherString = DEFAULT@SECLEVEL=2\n\n# after (trixie)\nopenssl version: OpenSSL 3.5.0\nMinProtocol = TLSv1.2\nCipherString = DEFAULT@SECLEVEL=3\n\ncustomer-b's endpoint:\n TLSv1.2, ECDHE-RSA-AES128-SHA, RSA 2048, SHA1 signature\ncustomer-c's endpoint:\n TLSv1.2, cipher fine, but the certificate chain is missing an intermediate", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "パラメータの設定が本番とステージングで違っていて、実機だけ止まる原因かもしれません:\n\n# staging (sim) — config/controller.sim.yaml\ncontroller:\n loop_rate: 20.0\n goal_tolerance: 0.02\n lidar_rate_expected: 10.0\n wrench_timeout: 5.0\n tf_buffer_duration: 10.0\n use_sim_time: true\n max_velocity: 0.5\n\n# production (hardware) — config/controller.hw.yaml\ncontroller:\n loop_rate: 20.0\n goal_tolerance: 0.01\n lidar_rate_expected: 10.0\n wrench_timeout: 5.0\n tf_buffer_duration: 1.0\n use_sim_time: false\n max_velocity: 0.5\n\n# 実機のログ（抜粋、1 時間に 40 回ほど）\n[ WARN] Lookup would require extrapolation into the past. Requested time 1753843321.401 but the earliest data is at time 1753843321.412\n[ERROR] Trajectory execution aborted: goal tolerance violated on joint_4 (0.0142 > 0.0100)\n[ INFO] controller reset, resuming\n\ntf_buffer_duration は去年、メモリ使用量を下げるために変更したものです。goal_tolerance を誰が変えたのかは記録が残っていません", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "ja"}
{"prompt": "github action for the rust indexer, cache never hits:\n\n- uses: actions/checkout@v4\n- uses: dtolnay/rust-toolchain@stable\n- uses: actions/cache@v4\n with:\n path: |\n ~/.cargo/registry\n target\n key: ${{ runner.os }}-cargo-${{ github.sha }}\n- run: cargo build --release\n- run: cargo test --all-features\n- run: cargo clippy -- -D warnings\n\nevery run: \"Cache not found for input keys: Linux-cargo-<sha>\"\nbuild time: 14 minutes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "this calculator has grown a parameter every time a country was added. same numbers out, better shape:\n\npublic Payslip calculate(Employee e, Period p, boolean includeBonus, boolean prorate,\n Country country, TaxYear year, boolean applyPensionCap,\n BigDecimal overrideRate, boolean skipSocial, List<Deduction> extra) {\n if (country == Country.FR && prorate) { /* 40 lines */ }\n else if (country == Country.DE) { /* 60 lines, ignores prorate */ }\n else if (country == Country.PT) { /* 30 lines, uses overrideRate if set */ }\n else { /* the original UK path, 80 lines */ }\n}\n\nfour call sites pass different combinations, and two of them pass nulls for parameters the branch ignores", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "unser Angular-Code hat drei Wege, dieselbe API zu rufen. Bitte vereinheitlichen, ohne Verhalten zu ändern:\n\n// altes Modul\nthis.http.get<Absence[]>('/api/v2/absences').subscribe(a => this.absences = a)\n\n// neueres Modul\nthis.absenceService.list().pipe(takeUntilDestroyed()).subscribe(a => this.absences.set(a))\n\n// neuestes Modul\nabsences = toSignal(inject(AbsenceService).list(), { initialValue: [] })\n\nvierzehn Komponenten insgesamt, drei davon vergessen das Abmelden, und der Fehlerfall wird nur in einem behandelt", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "de"}
{"prompt": "test fixtures for payroll are four builders that disagree about defaults:\n\nEmployee e1 = TestEmployees.uk(); // salaried, tax code 1257L, no pension\nEmployee e2 = new EmployeeBuilder().build(); // salaried, no tax code at all\nEmployee e3 = Fixtures.employee(FR); // hourly, with a pension scheme\nEmployee e4 = anEmployee().withSalary(50000).build(); // salaried, UK, pension at 5%\n\nabout 900 tests, and a test that passes with one builder often fails with another because of the pension default", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "planning input for the half, and i need a sequence rather than a wish list:\n\n- payroll engine migration has two months of parallel running left, and it has to finish before year end\n- a customer in Spain signs in september and we don't support Spanish social security at all\n- the timesheet screen is the top support complaint and is unusable above 200 entries\n- the indexer team wants to add three chains, each of which is a week of work plus ongoing RPC cost\n- our robot cell customer needs the certification audit passed by november or the deployment slips a year\n- two engineers are shared between payroll and the indexer and are context-switching badly\n- there's a compliance deadline in january for real-time payroll reporting in one country", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket that needs thinking, not code:\n\nPAY-620 — Multi-country payroll calculation\nThe calculator is one class with a country branch and 200 lines per country. Adding Spain means a fifth branch. Proposal is a rules engine with country packs loaded at runtime, so a country can be added without a deploy. Concerns raised: payroll rules change annually and must be versioned by tax year; auditors need to see exactly which rules produced a given payslip, years later; a rules engine makes the calculation harder to unit test than a plain class; and two of our countries have rules that genuinely need arbitrary code, not data.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer's roadmap request from the teams that depend on it:\n\n- three more chains, with the same API surface\n- historical backfill on demand rather than the current \"reindex everything\" script\n- per-contract lag metrics so a team can alert on their own contract falling behind\n- a way to reprocess a range after a decoding bug, without touching other contracts' data\n- read replicas, because the reporting queries are now competing with indexing writes\n- some story for reorgs deeper than our current 12-block assumption\n\none engineer, one quarter. what would you do and in what order", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "customer requirement for the robot cell, and the certification audit is in november:\n\n\"The safety function shall bring the manipulator to a controlled stop within 250 ms of a human entering the collaborative workspace. Detection shall be redundant, with no single sensor failure defeating the function. The safety function shall be independent of the application software and shall be verifiable without disassembly. Evidence shall include a documented worst-case latency analysis covering sensing, processing, communication and actuation.\"\n\nour perception pipeline alone measures 180ms worst case, the safety check runs in the same process as the motion controller, and we have two lidars but they feed one fusion node", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the payroll run screen, which is what customers stare at on the 25th:\n\nRun detail\n- Header: period, status (Draft / Calculating / Ready / Approved / Paid / Failed), employee count, total net. Status drives a coloured left border on the whole card.\n- Progress: during Calculating, a determinate bar with \"812 of 1,204 payslips\", updating over websocket, plus an elapsed timer.\n- Employee table: name, gross, deductions, net, a warning glyph where the payslip differs from last period by more than 20%.\n- Filters: only warnings, only changes, by department. Filters persist for the session.\n- Approve is a primary button, disabled unless status is Ready, with a confirmation dialog that restates the total and the employee count.\n- Failed state shows which employees failed, why, and a Retry failed button that does not touch the successful ones.\n- Everything must degrade gracefully when the websocket drops — fall back to polling, never show stale progress as live.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility audit of the employee portal, which our public sector customers care about:\n\n- The payslip PDF viewer is an iframe with no title and no text alternative; screen reader users get nothing.\n- The absence calendar is a table of divs; dates are not announced and arrow-key navigation does nothing.\n- Form errors appear only as red text under the field, not associated with the input and not announced.\n- The \"submit timesheet\" flow uses colour alone to indicate which days are incomplete.\n- Focus is lost to the top of the page after every modal closes.\n- Session timeout warning appears visually with a countdown that is never announced.\n- Contrast fails on the secondary button in both themes (3.1:1).", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the payroll module actually uses:\n\ntokens:\n color.text.default #1B1F23\n color.text.muted #5A6672\n color.status.warning #B26A00\n color.status.danger #B3261E\n space.1..6 4 8 12 16 24 32\n radius.sm/md/lg 4 8 12\n font.size.body 14/20\n font.size.caption 12/16\n\npayroll module: 14 hardcoded hex values, six of which are near-misses of the token colours; paddings of 6, 10 and 18px; two font sizes not in the scale; and a warning colour that fails contrast on the row background it's used with\n\nbring it onto the tokens and fix the contrast failure while you're there", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "integration spec our customer's HR system expects from us:\n\nGET /v2/exports/payroll?period=2026-07&format=sepa-xml\n auth: mutual TLS with a client cert we issue, plus an API key header\n response: 200 with the file, or 202 with a Location header if generation takes longer than 5 seconds\n the 202 path must be pollable and the result cached for 24 hours\n the file must be byte-identical on repeated requests for the same period unless a correction was posted\n a correction invalidates the cache and increments a `revision` in the filename\n they poll every 30 seconds from three of their servers, so concurrent identical requests must not generate the file three times\n file sizes are up to 40MB and they cannot handle chunked encoding", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for reorg-safe balances, needs implementing in the indexer:\n\nCREATE TABLE balance_deltas (\n id bigserial PRIMARY KEY,\n address bytea NOT NULL,\n token bytea NOT NULL,\n delta numeric(78,0) NOT NULL,\n block_number bigint NOT NULL,\n log_index int NOT NULL,\n UNIQUE (block_number, log_index)\n);\nCREATE INDEX ON balance_deltas (address, token, block_number);\n\nbalances become a sum over deltas up to a block height; a reorg deletes deltas above the fork point; the /v1/balances endpoint must answer at any height without scanning the whole history, and it's currently answering from a mutable balances table that reorgs corrupt", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "drop moment from the timesheet module", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "cargo cache key uses the sha", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "lower the indexer's batch to 200 blocks", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "la fecha del recibo sale en formato americano", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "es"}
{"prompt": "seclevel back to 2 for the outbound client", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "tf buffer duration to 10s on hardware", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "hashCode missing on the Money class", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "payroll calculator takes ten parameters, four of which are ignored on three of the four country paths, and two call sites pass nulls into branches that never read them. restructure it so each country's rules live somewhere coherent, with identical output for every payslip in the last twelve months as the acceptance criterion the last twelve months of payslips are the regression suite, so nothing may move by a cent.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "indexer holds a database transaction across an RPC call, which is why the pool exhausts whenever the provider is slow", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "our on-call has no alerting on payroll runs at all, and the obvious alerts would have caught tuesday's failure four hours earlier", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "the tax table loader falls back to the previous year when the current year's bands aren't loaded, silently, and the 2026 bands are not in yet. before we change anything i want to know exactly what that fallback produces on a real payslip and how we'd have noticed if a customer hadn't told us", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "das Bundle-Budget auf 1,5 MB anheben", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "de"}
{"prompt": "unwrap in db/cursor.rs, make it fallible", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "warning glyph on payslips that jumped 20%", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "sticky name column on the week view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "empty cells should show an em dash", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "chain selector in the indexer console", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "休暇カレンダーの矢印キー操作が効きません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
{"prompt": "secondary button contrast fails in both themes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "focus jumps to the top after a modal closes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "conflict border should be amber, not red", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "totals row scrolls away", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "`RunProcessor` per-country strategies", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "decode table instead of 40 match arms", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "un seul builder pour les tests de paie", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "fr"}
{"prompt": "`gross_cents` naming, everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "pull the retry policy out of the rpc client", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "inline `minutes()`, one caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "signals everywhere in the absence module", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "javadoc on the payroll calculator, please", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "changelog entry for the reorg fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "kurze Notiz zur Parallelabrechnung", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "de"}
{"prompt": "document the retro absence behaviour", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the safety concept for the auditor", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the balance deltas change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "¿el indexador maneja bien las reorganizaciones?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "can two runs touch the same payslip?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the approval flow", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "payslips missing for 400 employees", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "arm drifts over a shift", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "webhooks to two customers fail TLS", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "warum hängt der Indexer nach einer Reorg?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for per-contract indexing lag", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "algo pequeno para hoje", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "pt"}
{"prompt": "carry on where that left off", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidier, please", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "grid, you know", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "next one on the list", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "same but for Spain", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "unblock the robot people", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "faster, ideally", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "another look at that screen", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "finish the migration bit", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "le truc d'hier, la suite", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "fr"}
{"prompt": "start wherever you like", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "absences API is integrated against by six customers and documented nowhere, which is why we get the same three bugs filed repeatedly — the 404 instead of 403, the retro flag, and half days. write the reference page from the controller's actual behaviour, with the surprising parts called out rather than buried in a table", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "deployment procedure for the indexer lives in one engineer's head and includes at least two steps that will corrupt balances if skipped. write it up as a runbook: the pre-deploy checks, the manual stop, the migration step, how to tell within two minutes whether it worked, and exactly what rollback costs us in lost data", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "support answers \"when does an absence affect pay\" differently every time, and the honest answer involves retro flags, corrections on the next run, and a case where the correction is silently dropped. write the page that settles it, in language an HR administrator understands, and be explicit about the dropped-correction case rather than omitting it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "reorg handler walks back one block at a time to find a common ancestor and deletes forward with a cascade to balances, and i want to understand what that does during a twelve-block reorg while the indexer is already behind. no changes yet — i want to know what actually happens, including what a reader sees mid-rollback", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "RFC proposing per-employee payroll jobs mentions that partial runs become customer-visible and then moves on, which is the part i'd have thought hardest. read it against how runs work today and tell me whether the consequences section is complete, particularly around approval before all jobs finish i would rather know now than after we have built the queue.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "four addresses have balances that disagree with the chain, all of them holding a token whose Transfer event indexes the value parameter, unlike every other token we index. work out whether our decoder is silently producing zero for those, and how many other contracts we index have the same shape i also want to know how many other contracts we index emit the same event shape.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "timesheet grid needs to survive five hundred rows without falling over, which means virtualising it, but the sticky employee column and the optimistic totals have to keep working while scrolling. rebuild it to the spec, keep inline editing and keyboard navigation exactly as designed, and make sure conflicts are still visible when a row is partially scrolled", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "payroll run screen shows progress over a websocket and simply freezes when the socket drops, which during a run is indistinguishable from the run being stuck. add a polling fallback, make stale progress visibly stale rather than silently wrong, and keep the approve button's guard conditions exactly as they are it should also survive the tab being backgrounded for ten minutes and brought back.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "safety architecture needs redesigning for certification and there's a piece we can start regardless: separating the safety check into its own process with its own watchdog. give me the design for the whole thing first, then do that separation so we have something to measure assume the auditor will ask for the latency budget in writing, with measurements.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "unsere Zeiterfassung ist auf Wochenbasis gebaut und ein Kunde braucht Schichtmodelle über Mitternacht hinweg. Ich hätte gern zuerst ein Konzept, wie das Datenmodell aussehen müsste, und danach die Migration der bestehenden Einträge", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "de"}
{"prompt": "real-time payroll reporting becomes a legal requirement in one country in january and we currently report monthly in a batch. map out what compliance means for our architecture, then start on whichever piece has the longest lead time — my guess is the submission client, but tell me if it isn't", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "parallel-run process for the payroll migration exists only as folklore and a gist. write it up properly as a runbook, and while you're in the diff script, make it fail loudly when it can't reach one of the two databases instead of reporting zero differences the finance lead's email sign-off should become something we can actually find later.", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "escreve a documentação da API de exportação para o cliente e confirma no código se o ficheiro é mesmo idêntico entre pedidos repetidos, porque é isso que estamos a prometer", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "pt"}
{"prompt": "three employees got the wrong social security bands and all three had a contract amendment mid-month, which suggests the cap isn't being prorated. confirm that from the code, then fix it and tell me how many past payslips are affected i would also like to know whether mid-month terminations hit the same proration bug.", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "robot stops mid-path about once a day and the lidar's publishing rate is wildly variable in the logs. work out whether that's the sensor, the USB bus or our own callback blocking, and once you know, put the diagnostic in place that would tell us next time without a manual dump", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like to understand what our launch file actually guarantees about node startup order on hardware", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "is it expected that the indexer's cursor is persisted before the commit rather than after", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "docs/payroll.md describes the old sequential run and the retry semantics we removed", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "api changelog needs an entry for the balances endpoint's block-height parameter", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer-facing note about the late payment, apologetic but factual, one paragraph", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "necesitamos documentar qué hace el flag `dual_write` durante la migración, nadie se acuerda", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "es"}
{"prompt": "dates differ between the UI and PDF", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "goal tolerance on hardware is half what it is in sim, and nobody knows who changed it or why", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "per-contract cursors in the indexer, so one slow contract doesn't hold up everything else", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "how should we version country payroll rules so an auditor can reproduce a payslip from three years ago", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test payroll calculations, given that a wrong answer is a legal problem rather than a bug", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "two engineers are split across payroll and the indexer and neither project is moving, what would you do about the allocation", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "what should the story be for customers who want their payroll data in their own warehouse, three have asked now", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "run detail screen needs the failed-employee list with a retry that skips the successful ones", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "absence calendar should show public holidays for the employee's country, greyed and non-selectable", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "indexer console needs a reorg history view, so we can see when balances were rolled back", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "reporting screen times out on our biggest customer and the obvious fix is pagination, which finance will hate", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "whatever is on fire", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "other half of that", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "deduction-line ordering differs between the old and new payroll engines, which the migration diff flags every month and we've been waving through as cosmetic. work out whether the order is actually meaningful for the payslip PDF and the bank file, make the new engine match wherever it is, and then write down what \"acceptable difference\" means so the next person isn't guessing", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "topic names are hardcoded as string literals in forty places across the ROS packages, with two typos that only bite in one launch configuration. centralise them properly, and while you're there tell me whether the two typo'd topics were ever connected to anything or have been silently dead since the port to Jazzy", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "`PayrollService` does payslip generation, PDF rendering and bank file writing in one class of about nine hundred lines, and the bank file part is the bit under audit. split it along those three responsibilities, then document which class owns what so the auditor's questions have an obvious answer", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "our angular error handling is three parsers deep because each spring service invented its own error shape. unify the server side onto one shape, and confirm from the client code which of the three parsers is still reachable before you delete anything", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "employee test fixtures exist in four flavours with different pension defaults, which is why moving a test between packages changes its outcome. consolidate onto one builder, then write the short note on fixture conventions that should have existed before the fourth one appeared about nine hundred tests depend on these, so the migration has to be mechanical.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "i want to know whether a parallel stream over employees can corrupt the run total — the entity has a mutable long that every thread adds to — and if it can, the fix, with a test that reproduces it reliably rather than one that passes by luck the run total is a mutable long on the entity, which is the part that worries me.", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "angular timesheet grid recomputes row state in a template getter on every change detection pass, which i think explains both the stack overflow and the changed-after-checked error. confirm the mechanism from the code, then tell me the smallest change that fixes it without the rewrite we've been putting off", "purpose": "review", "secondary": "planning", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "before i touch the calculator i'd like to understand how an absence becomes a deduction line — which service decides the daily rate, what happens with a half day, and where the retro flag enters — and then have the tax table cache invalidation documented, because i can't find the call at all", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "we need per-contract cursors in the indexer so one slow contract doesn't hold up the rest, but that changes what \"indexed up to block N\" means for the API and for our lag alerts. decide the semantics with me first, then implement the cursor split", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "error responses differ per spring service — some return a problem-details object, some a bare string, one an html error page from the container — and the angular client has grown a parser for each. settle on one shape across the services, keep every status code as it is, and make sure the html case can't happen at all", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "payslip generation, PDF rendering and bank file writing share one class and one set of tests, so a change to the PDF layout requires understanding the bank file format. separate them with the same public entry points, and keep the generated output byte-identical for the last three periods as the acceptance test", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "nobody can tell me how a payslip correction gets matched back to the absence that caused it, which matters because the correction line on the PDF shows only the absence type. trace it through and explain the matching, including what happens when two absences of the same type land in the same closed period", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "leavers keep their portal access until the next payroll run processes their termination, which HR has now raised as a compliance problem rather than an inconvenience. revoke access at the termination date instead, keep payslip access for the statutory period, and make sure a termination entered in error can be reversed without a support ticket", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a nightly job should flag employees whose net pay has moved more than twenty percent since the last period, before the run is approved rather than after someone complains. thresholds per organisation, an obvious way to acknowledge a flag, and the flags need to survive a recalculation of the run without being silently cleared", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "the `Run` entity collides with three other Runs across the java service — the payroll one, an import run, a robot cell test run — and every import block has to disambiguate. rename the payroll one throughout, including the JPA table mapping if that can be done without a migration, and check nothing depends on the class name reflectively", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "who else defines a `Run` type?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "why does row state recompute constantly?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "one employee builder for the tests", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt":"I inherited FoxglovePineMetricsStore and need a careful read of projects/foxglove/services/ledger/replay.go before I can sign off on the next release. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to FoxglovePineMetricsStore and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveLumenChartStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/foxglove/cmd/exporter/main.py and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveNimbusFormCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Two asks around FoxgloveSableParserCoordinator: (1) assess ownership and failure handling in projects/foxglove/db/migrations/20260730_events.sql; (2) capture the contract and rollback note for consumers. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"What does FoxgloveHarborIndexStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Sable: Two deliverables are holding up FoxgloveFernSnapshotCoordinator. First, assess ownership and failure handling in projects/foxglove/Sources/App/SessionStore.swift. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/foxglove/Sources/App/SessionStore.swift, which follows Cloudflare Workers conventions and currently suffers from an accessibility label that reads the internal enum. Cover the awkward empty and retry states.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Tide: projects/foxglove/ui/settings/PrivacyPane.tsx の FoxgloveSummitProxyFlow で、GraphQL の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- GraphQL を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は FoxgloveSummitProxyFlow のみ","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"ja"}
{"prompt":"Release engineering needs a FoxgloveKiteSchedulerService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"For FoxgloveGarnetModalCoordinator, change FoxgloveGarnetModalCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, give the existing implementation a read-only safety pass. Work from projects/foxglove/internal/auth/refresh.go, stay with Kafka, and cover the awkward empty and retry states. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-46118\n\n08:02 deploy FoxgloveCedarPolicyFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nUsing this as the starting evidence, propose a staged FoxgloveCedarPolicyFlow migration with compatibility seams, owners, canary metrics, rollback gates, and a no-code first milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveAcornWidgetCoordinator is blocking the next release because an empty state that flashes before cached data arrives. I need two concrete outcomes from a single pass: change FoxgloveAcornWidgetCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing Spring Boot conventions in projects/foxglove/db/migrations/20260730_events.sql; cover the awkward empty and retry states. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_46157'\n AND e.created_at >= now() - interval '24 hours'\nGROUP BY e.tenant_id, e.stream_id;\n\nHashAggregate (cost=184922.10..185011.81 rows=8971 width=40) (actual time=8421.294..8422.551 rows=123 loops=1)\n Group Key: e.tenant_id, e.stream_id\n Batches: 1 Memory Usage: 945kB\n -> Hash Join (cost=2118.42..181004.17 rows=522391 width=32) (actual time=42.118..8279.405 rows=918412 loops=1)\n Hash Cond: ((e.tenant_id = s.tenant_id) AND (e.stream_id = s.id))\n -> Bitmap Heap Scan on event_log e (actual time=18.602..7922.884 rows=1261044 loops=1)\n Recheck Cond: (tenant_id = 't_46157'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDeliver the FoxgloveBeaconStoreCoordinator server-side capability implied above: durable cursors, tenant authorization, idempotent retries, bounded work, telemetry, and focused integration coverage.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Pin FoxgloveAsterWebhookService's Kafka dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Umbra: Ticket OPS-46155: retire the legacy replay path for FoxgloveAmberFilterCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible FoxgloveAmberFilterCoordinator rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Split FoxgloveCedarPolicyStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveBasilRunnerCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Bring FoxgloveMapleQueueStore's confirmation sheet in line with the design tokens, including destructive emphasis, dark appearance, Dynamic Type, and swipe-to-dismiss behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Vela: Two deliverables are holding up FoxgloveQuartzPlayerCoordinator. First, separate FoxgloveQuartzPlayerCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/foxglove/ui/settings/PrivacyPane.tsx, which follows GraphQL conventions and currently suffers from a flaky snapshot caused by locale-dependent sorting. Cover the awkward empty and retry states.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveBirchMigratorCoordinator: handle the lingering thing","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'FoxglovePrismCacheFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[FoxglovePrismCacheFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/foxglove/cmd/exporter/main.py:144: error: -[FoxglovePrismCacheFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[FoxglovePrismCacheFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Bring FoxglovePrismCacheFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Willow: The first FoxgloveAtlasSearchFlow request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveVelaDrawerCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Xylem: Ticket OPS-46141: retire the legacy replay path for FoxgloveSpruceDaemonFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current FoxgloveSpruceDaemonFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Three teams extended FoxgloveAmberFilterService independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Separate those responsibilities into focused units, remove the duplicated normalization branches, and keep public types, wire values, log fields, timing, and test-observable behavior exactly the same.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Spring Boot operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"FoxgloveHarborIndexCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Yarrow: The API work is done; what remains for FoxgloveAcornWidgetStore is the visible interaction layer across loading, offline, empty, and success cases. Bring the drawer and detail pane to production polish with fluid sizing, honest skeletons, focus restoration, accessible announcements, and touch targets that survive large text.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveAcornWidgetStore\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Zephyr: Two asks around FoxgloveMoonlitSDKCoordinator: (1) finish FoxgloveMoonlitSDKCoordinator's responsive empty and retry states; (2) give the existing implementation a read-only safety pass. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"A previously stable test around FoxgloveOrbitSyncFlow now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveRainfallDBCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Checkout: Incident timeline — INC-46130\n\n08:02 deploy FoxgloveSableParserFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nUsing this as the starting evidence, propose a staged FoxgloveSableParserFlow migration with compatibility seams, owners, canary metrics, rollback gates, and a no-code first milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"For FoxglovePrismCacheCoordinator, finish FoxglovePrismCacheCoordinator's responsive empty and retry states; once that is complete, correct the known stale timeout beside it. Work from projects/foxglove/ml/pipeline/features.py, stay with Cloudflare Workers, and cover the awkward empty and retry states. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Does FoxgloveCoralUploadFlow enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"// projects/foxglove/pkg/cache/lease.rs\nfinal class FoxgloveCinderAuthFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit FoxgloveCinderAuthFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveBeaconStoreFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/foxglove/services/ledger/replay.go and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Exporter: Incident timeline — INC-46150\n\n08:02 deploy FoxgloveMarbleTokenCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the FoxgloveMarbleTokenCoordinator decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Why does FoxgloveBeaconStoreStore's Kafka worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Scheduler: Incident timeline — INC-46124\n\n08:02 deploy FoxgloveCraneWorkspaceFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the material above into a concise FoxgloveCraneWorkspaceFlow release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"Extract FoxgloveFernSnapshotService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"A copied hex color in FoxgloveWrenExportFlow lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for FoxgloveLedgerGateCoordinator:\n- primary outcome: produce a consumer guide for FoxgloveLedgerGateCoordinator\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/foxglove/apps/console/routes/usage.svelte\n- platform constraint: Spring Boot\n- known complication: lease renewal code copied across three workers\n\nBoth results are required, but they should remain independently reviewable. Cover the awkward empty and retry states; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Spell FoxgloveGarnetModalStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"FoxgloveDriftConsoleCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"FoxgloveTideWorkerCoordinator needs a paired pass: produce a consumer guide for FoxgloveTideWorkerCoordinator, plus give the existing implementation a read-only safety pass. Use projects/foxglove/app/src/main/SyncWorker.kt as the source of truth, preserve the Spring Boot contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"The FoxgloveMicaProfileStore surface in projects/foxglove/services/ledger/replay.go is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Why does FoxgloveVelaDrawerStore's Cloudflare Workers worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"# projects/foxglove/ui/settings/PrivacyPane.tsx\n[worker.foxglovecopperbridgeflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovecopperbridgeflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovecopperbridgeflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveCopperBridgeFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46121\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/foxglove/ui/settings/PrivacyPane.tsx and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"We need to move FoxgloveFlintTimelineStore from the legacy store to GraphQL. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"FoxgloveCloudReconcilerCoordinator: polish, then correct","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Give FoxgloveAsterWebhookStore a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a FoxgloveBirchMigratorStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"We need to move FoxgloveMarbleTokenStore from the legacy store to Spring Boot. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"What sequence would let FoxgloveSpruceDaemonStore adopt GraphQL with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind FoxgloveBirchMigratorService's Spring Boot choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"PM is preparing the FoxgloveFrostPanelService rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveFrostPanelService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Dashboard: projects/foxglove/ui/settings/PrivacyPane.tsx has grown through several launches, and FoxgloveSummitProxyService now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing GraphQL deployment\n- keep the work scoped to FoxgloveSummitProxyService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/foxglove/internal/auth/refresh.go b/projects/foxglove/internal/auth/refresh.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/internal/auth/refresh.go\n+++ b/projects/foxglove/internal/auth/refresh.go\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is FoxgloveBasilRunnerFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Worker: // projects/foxglove/config/staging.toml\nfinal class FoxgloveAtlasSearchCoordinatorCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Walk through what the artifact proves about FoxgloveAtlasSearchCoordinator; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveSpruceDaemonCoordinator: could this be clearer","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-46137: retire the legacy replay path for FoxgloveMicaProfileFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. From this evidence, draft consumer-facing migration guidance for FoxgloveMicaProfileFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Simulator: // projects/foxglove/infra/modules/edge/main.tf\nfinal class FoxgloveFrostPanelFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nRestructure FoxgloveFrostPanelFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveLumenChartCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current FoxgloveJuniperCLIStore design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveJuniperCLIStore\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveEmberRelayCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-46152\n\n08:02 deploy FoxgloveMosaicGridCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for FoxgloveMosaicGridCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Style FoxgloveLedgerGateService's offline state","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveDeltaCanvasCoordinator needs a paired pass: ship the idempotent FoxgloveDeltaCanvasCoordinator replay endpoint, plus capture the contract and rollback note for consumers. Use projects/foxglove/ui/settings/PrivacyPane.tsx as the source of truth, preserve the GraphQL contract, and avoid unrelated cleanup.","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Serve FoxglovePrismCacheService health checks","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-46122: retire the legacy replay path for FoxgloveAsterWebhookFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess FoxgloveAsterWebhookFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Runbook: projects/foxglove/infra/modules/edge/main.tf now contains FoxgloveBasilRunnerStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveFlintTimelineCoordinator: sort out the rough edge","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new FoxgloveAmberFilterStore adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Since the last release, FoxgloveSlateEditorService has shown a feature flag whose default differs between environments; nobody on the team can reproduce it reliably on a laptop. Trace task lifetime, cursor advancement, and durable acknowledgment across reconnects; produce a defensible root cause and the smallest experiment that would falsify it.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to FoxgloveSlateEditorService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Trace: projects/foxglove/app/src/main/SyncWorker.kt 里的 FoxgloveRavenSessionService 最近在 Spring Boot 流程中出现间歇性问题。 请写一份面向调用方的说明，包含 contract、错误、retry 和可复制示例，不要改 handler。\n\n约束：\n- 继续使用 Spring Boot\n- 保持兼容性和取消语义\n- 改动只限于 FoxgloveRavenSessionService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"zh"}
{"prompt":"FoxgloveAsterWebhookCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Diff: projects/foxglove/services/ledger/replay.go has grown through several launches, and FoxgloveBeaconStoreService now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to FoxgloveBeaconStoreService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Before we approve FoxgloveCinderAuthStore, assess whether two validators with subtly different error strings is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The FoxgloveAmberFilterFlow surface in projects/foxglove/apps/console/routes/usage.svelte is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveCedarPolicyCoordinator: diagnose, then correct","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Profiler: The FoxgloveLumenChartService empty state in projects/foxglove/ml/pipeline/features.py needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating an accessibility label that reads the internal enum in FoxgloveMosaicGridStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Does FoxgloveCloudReconcilerService preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Extract FoxgloveOspreyJobStore's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"FoxgloveAtlasSearchStore's metric is misspelled as succesful_total in one declaration. Correct that literal and its exact test expectation, without renaming anything else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"// projects/foxglove/engine/render/atlas.cpp\nfinal class FoxgloveFlintTimelineFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nRestructure FoxgloveFlintTimelineFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Introduce a durable deduplication key for FoxgloveDriftConsoleService events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveSlateEditorCoordinator is blocking the next release because timestamps rendered one day ahead near UTC midnight. I need two concrete outcomes from a single pass: assess ownership and failure handling in projects/foxglove/packages/api/openapi.yaml, and capture the contract and rollback note for consumers. Use the existing Kotlin coroutines conventions in projects/foxglove/packages/api/openapi.yaml; cover the awkward empty and retry states. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveCopperBridgeCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Make FoxgloveJuniperCLIService keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Console: # projects/foxglove/ml/pipeline/features.py\n[worker.foxglovewrenexportcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovewrenexportcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovewrenexportcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveWrenExportCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46159\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nMake the one confirmed configuration correction in projects/foxglove/ml/pipeline/features.py. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveCinderAuthCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"FoxglovePineMetricsCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Give FoxgloveEchoRegistryStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Decouple FoxgloveDeltaCanvasService's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Summarize the FoxgloveCopperBridgeService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The behavior of FoxgloveLedgerGateStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/foxglove/apps/console/routes/usage.svelte. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Spring Boot operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Describe FoxgloveOpalRouterService's error envelope","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"// projects/foxglove/engine/render/atlas.cpp\nfinal class FoxgloveJuniperCLIFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate FoxgloveJuniperCLIFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Workspace: Ticket OPS-46131: retire the legacy replay path for FoxgloveDeltaCanvasFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess FoxgloveDeltaCanvasFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Por que FoxgloveNovaPickerService trava?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"pt"}
{"prompt":"FoxgloveKiteSchedulerCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Store FoxgloveCloudReconcilerStore's delivery receipts","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"FoxgloveRavenSessionCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Repository: // projects/foxglove/infra/modules/edge/main.tf\nfinal class FoxgloveGarnetModalFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit FoxgloveGarnetModalFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a FoxgloveMosaicGridFlow changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Pipeline: # projects/foxglove/src/sync/reconcile.ts\n[worker.foxgloveacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxgloveacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxgloveacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46110\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nAlign FoxgloveAcornWidgetFlow's staging timeout with the shown production value and refresh only the focused config test; nothing else in the paste should move.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"En projects/foxglove/ui/settings/PrivacyPane.tsx, FoxgloveQuartzPlayerStore tiene un problema intermitente en el flujo de GraphQL. Propón fases, compatibilidad, métricas, rollback y ownership; detente antes de tocar código.\n\nRestricciones:\n- seguir con GraphQL\n- conservar compatibilidad y cancelación\n- limitar el cambio a FoxgloveQuartzPlayerStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con GraphQL alrededor de FoxgloveQuartzPlayerStore.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"es"}
{"prompt":"Gateway: Ticket OPS-46135: retire the legacy replay path for FoxgloveRavenSessionFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current FoxgloveRavenSessionFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Renderer: The name pendingAck means two different things across FoxgloveNimbusFormService's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"For FoxgloveOpalRouterCoordinator, assess ownership and failure handling in projects/foxglove/engine/render/atlas.cpp; once that is complete, capture the contract and rollback note for consumers. Work from projects/foxglove/engine/render/atlas.cpp, stay with GraphQL, and cover the awkward empty and retry states. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveEchoRegistryCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new FoxgloveVelaDrawerService adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Read projects/foxglove/Sources/App/SessionStore.swift and tell me whether FoxgloveWillowCodecService can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Could FoxgloveMarbleTokenFlow show the active Spring Boot sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Since the last release, FoxgloveCoralUploadStore has shown a misleading timeout name used in five packages; nobody on the team can reproduce it reliably on a laptop. Trace task lifetime, cursor advancement, and durable acknowledgment across reconnects; produce a defensible root cause and the smallest experiment that would falsify it.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to FoxgloveCoralUploadStore and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Center the FoxgloveTideWorkerStore modal","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Spell FoxgloveCraneWorkspaceStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-46123: retire the legacy replay path for FoxgloveCloudReconcilerFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCapture the FoxgloveCloudReconcilerFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveJuniperCLICoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Two asks around FoxgloveNovaPickerCoordinator: (1) change FoxgloveNovaPickerCoordinator's known staging timeout from 15 to 30 seconds; (2) capture the contract and rollback note for consumers. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveKiteSchedulerStore's staging timeout is already known to be wrong: change the single projects/foxglove/pkg/cache/lease.rs value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Trace FoxgloveHarborIndexService's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current FoxgloveWrenExportService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveWrenExportService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two asks around FoxgloveCraneWorkspaceCoordinator: (1) find the unknown cause of a deadlock that appears only during shutdown; (2) correct the known stale timeout beside it. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"UI ticket DES-46154: finish the compact FoxgloveIrisBatchCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/foxglove/Sources/CLI/Commands/Doctor.swift\nFramework: Cloudflare Workers\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible FoxgloveIrisBatchCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Indexer: // projects/foxglove/Sources/CLI/Commands/Doctor.swift\nfinal class FoxgloveFernSnapshotFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nAdd the bounded FoxgloveFernSnapshotFlow replay flow described here, including authorization, key rotation, cancellation, lag metrics, and tests for malformed and cross-tenant cursors.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/foxglove/ml/pipeline/features.py b/projects/foxglove/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/ml/pipeline/features.py\n+++ b/projects/foxglove/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is FoxgloveLumenChartFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-46126\n\n08:02 deploy FoxgloveOpalRouterFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current FoxgloveOpalRouterFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"The data is already available in projects/foxglove/Sources/CLI/Commands/Doctor.swift; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Split FoxgloveOspreyJobService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveMapleQueueCoordinator: polish the last piece","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Apparently: # projects/foxglove/apps/console/routes/usage.svelte\n[worker.foxgloveechoregistryflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxgloveechoregistryflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxgloveechoregistryflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveEchoRegistryFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46145\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/foxglove/apps/console/routes/usage.svelte and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Milestones for replacing FoxglovePineMetricsService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Does FoxglovePrismCacheStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: FoxgloveAcornWidgetService has one known configuration mistake in projects/foxglove/src/sync/reconcile.ts, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to FoxgloveAcornWidgetService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"// projects/foxglove/Sources/App/SessionStore.swift\nfinal class FoxgloveWillowCodecFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nWalk through what the artifact proves about FoxgloveWillowCodecFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Fresh release brief for FoxgloveFrostPanelCoordinator:\n- primary outcome: change FoxgloveFrostPanelCoordinator's known staging timeout from 15 to 30 seconds\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/foxglove/internal/auth/refresh.go\n- platform constraint: Kafka\n- known complication: lost focus when the drawer animation finishes\n\nBoth results are required, but they should remain independently reviewable. Cover the awkward empty and retry states; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-46143: retire the legacy replay path for FoxgloveEmberRelayFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible FoxgloveEmberRelayFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/foxglove/ml/pipeline/features.py b/projects/foxglove/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/ml/pipeline/features.py\n+++ b/projects/foxglove/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate FoxgloveRainfallDBFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a FoxgloveNimbusFormStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveMicaProfileCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Give FoxgloveMapleQueueService's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Warum hängt FoxgloveRainfallDBStore?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"Lately: // projects/foxglove/engine/render/atlas.cpp\nfinal class FoxgloveOrbitSyncCoordinatorCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit FoxgloveOrbitSyncCoordinator by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Oddly: diff --git a/projects/foxglove/app/src/main/SyncWorker.kt b/projects/foxglove/app/src/main/SyncWorker.kt\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/app/src/main/SyncWorker.kt\n+++ b/projects/foxglove/app/src/main/SyncWorker.kt\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure FoxgloveLedgerGateFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Map FoxgloveCopperBridgeStore's ownership split","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Dedupe FoxgloveCedarPolicyService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"On compact widths, FoxgloveIrisBatchFlow's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"The minimum supported GraphQL version in projects/foxglove/engine/render/atlas.cpp is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-46134\n\n08:02 deploy FoxgloveNimbusFormFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for FoxgloveNimbusFormFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Design the FoxgloveGarnetModalService rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Corrige le timeout de FoxgloveNovaPickerStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"fr"}
{"prompt":"Move FoxgloveSpruceDaemonService's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Store FoxgloveTideWorkerService's delivery receipts","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Pin FoxgloveSableParserService's Spring dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"projects/foxglove/packages/api/openapi.yaml の FoxgloveEmberRelayService で、Kotlin coroutines の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- Kotlin coroutines を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は FoxgloveEmberRelayService のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"ja"}
{"prompt":"Please resist widening this one: FoxgloveSlateEditorStore works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveSlateEditorStore\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe cause and exact value change are already known, so keep this as a contained correction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-46128: finish the compact FoxgloveOspreyJobFlow filter experience\n\nRoute: /catalog/search\nSource: projects/foxglove/crates/index/src/segment.rs\nFramework: Kotlin coroutines\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nUse the UI evidence to complete FoxgloveOspreyJobFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Why does FoxgloveSummitProxyStore's GraphQL worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'FoxgloveVelaDrawerFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[FoxgloveVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/foxglove/cmd/exporter/main.py:144: error: -[FoxgloveVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[FoxgloveVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nUse the UI evidence to complete FoxgloveVelaDrawerFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Currently: diff --git a/projects/foxglove/workers/thumbnail/consumer.ex b/projects/foxglove/workers/thumbnail/consumer.ex\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/workers/thumbnail/consumer.ex\n+++ b/projects/foxglove/workers/thumbnail/consumer.ex\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nSplit FoxgloveQuartzPlayerFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Today: // projects/foxglove/db/migrations/20260730_events.sql\nfinal class FoxgloveBirchMigratorFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate FoxgloveBirchMigratorFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveOspreyJobCoordinator needs a paired pass: produce a consumer guide for FoxgloveOspreyJobCoordinator, plus give the existing implementation a read-only safety pass. Use projects/foxglove/pkg/cache/lease.rs as the source of truth, preserve the Kotlin coroutines contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Context: # projects/foxglove/workers/thumbnail/consumer.ex\n[worker.foxglovesummitproxycoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovesummitproxycoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovesummitproxycoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveSummitProxyCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46151\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nThe intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/foxglove/workers/thumbnail/consumer.ex and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Background: projects/foxglove/config/staging.toml 里的 FoxgloveEmberRelayStore 最近在 Kotlin coroutines 流程中出现间歇性问题。 请给出阶段、兼容层、指标、rollback 和 ownership，先不要修改代码。\n\n约束：\n- 继续使用 Kotlin coroutines\n- 保持兼容性和取消语义\n- 改动只限于 FoxgloveEmberRelayStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"FoxgloveMosaicGridService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Kafka operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Question: diff --git a/projects/foxglove/config/staging.toml b/projects/foxglove/config/staging.toml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/config/staging.toml\n+++ b/projects/foxglove/config/staging.toml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure FoxgloveMoonlitSDKFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Observation: Incident timeline — INC-46120\n\n08:02 deploy FoxgloveHarborIndexFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFind the source of this FoxgloveHarborIndexFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Constraint: The public surface of FoxgloveMarbleTokenService is frozen, but its internal ownership in projects/foxglove/db/migrations/20260730_events.sql is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveMarbleTokenService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/foxglove/engine/render/atlas.cpp, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Request: The public surface of FoxgloveOrbitSyncService is frozen, but its internal ownership in projects/foxglove/lib/codec/frame.cc is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveOrbitSyncService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Goal: # projects/foxglove/apps/console/routes/usage.svelte\n[worker.foxglovetideworkerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovetideworkerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovetideworkerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveTideWorkerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46125\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nAlign FoxgloveTideWorkerFlow's staging timeout with the shown production value and refresh only the focused config test; nothing else in the paste should move.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Symptom: // projects/foxglove/web/components/FilterDrawer.vue\nfinal class FoxglovePineMetricsFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nWalk through what the artifact proves about FoxglovePineMetricsFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveWillowCodecCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Headsup: Incident timeline — INC-46146\n\n08:02 deploy FoxgloveDriftConsoleFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the artifact into a reversible FoxgloveDriftConsoleFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"FYI: Incident timeline — INC-46113\n\n08:02 deploy FoxgloveSlateEditorFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Reconstruct the FoxgloveSlateEditorFlow failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Meanwhile: Incident timeline — INC-46148\n\n08:02 deploy FoxgloveKiteSchedulerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why FoxgloveKiteSchedulerFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-46158\n\n08:02 deploy FoxgloveCoralUploadCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for FoxgloveCoralUploadCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Split FoxgloveOpalRouterStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Design the FoxgloveSableParserStore rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Locally: projects/foxglove/pkg/cache/lease.rs now contains FoxgloveCinderAuthService's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Polish the FoxgloveDeltaCanvasStore toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"FoxgloveCoralUploadService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Kotlin coroutines operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"The minimum supported Kafka version in projects/foxglove/internal/auth/refresh.go is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Production: The FoxgloveEchoRegistryService surface in projects/foxglove/apps/console/routes/usage.svelte is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Em projects/foxglove/apps/console/routes/usage.svelte, o FoxgloveRavenSessionStore tem um problema intermitente no fluxo de Spring Boot. Leia o fluxo atual e avalie ownership, cancelamento e ordem; preciso apenas da análise.\n\nRestrições:\n- continuar com Spring Boot\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao FoxgloveRavenSessionStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"A copied hex color in FoxgloveMicaProfileService lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"En projects/foxglove/packages/api/openapi.yaml, FoxgloveAtlasSearchService tiene un problema intermitente en el flujo de Kotlin coroutines. Lee el flujo actual y dime si ownership, cancelación y orden son seguros; solo necesito el análisis.\n\nRestricciones:\n- seguir con Kotlin coroutines\n- conservar compatibilidad y cancelación\n- limitar el cambio a FoxgloveAtlasSearchService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"Any races in FoxgloveMoonlitSDKService?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Ownership of FoxgloveWrenExportStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Cloudflare Workers operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"In projects/foxglove/workers/thumbnail/consumer.ex hat FoxgloveQuartzPlayerService ein sporadisches Problem im GraphQL-Ablauf. Lies den aktuellen Ablauf und bewerte Ownership, Abbruch und Reihenfolge; ich brauche nur die Analyse.\n\nRandbedingungen:\n- GraphQL weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf FoxgloveQuartzPlayerService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um FoxgloveQuartzPlayerService mit GraphQL kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"de"}
{"prompt":"Read projects/foxglove/engine/render/atlas.cpp and tell me whether FoxgloveOrbitSyncStore can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Clarify FoxgloveMoonlitSDKStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveFrostPanelStore needs a production server path for replaying tenant events; the public envelope is agreed but persistence and retry handling are not wired. Implement the endpoint and durable cursor, enforce tenant authorization and idempotency, emit useful spans, cap work per request, and include focused tests for retries, cancellation, and malformed cursors.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Kafka operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-46147: retire the legacy replay path for FoxgloveMapleQueueFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCapture the FoxgloveMapleQueueFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Cadre la migration de FoxgloveRainfallDBService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"fr"}
{"prompt":"Make FoxgloveCraneWorkspaceService keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about FoxgloveFernSnapshotStore, but the current prose in projects/foxglove/Sources/App/SessionStore.swift only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to FoxgloveFernSnapshotStore and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: FoxgloveIrisBatchService has one known configuration mistake in projects/foxglove/Sources/App/SessionStore.swift, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to FoxgloveIrisBatchService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The FoxgloveWillowCodecStore feature flag default should be false in test, exactly like production; correct that config entry and nothing else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-46127\n\n08:02 deploy FoxgloveNovaPickerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why FoxgloveNovaPickerFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}