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-02.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "a consultant reviewed our compose code and left a list of \"performance issues\" that i'm not sure i believe — unstable lambdas, missing keys in lazy lists, derivedStateOf everywhere, and a claim that our whole schedule screen recomposes on every scroll tick. check the actual code and tell me which of those are real for us", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "our accessibility story on android is \"we ran the scanner once\". i'd like a plan for getting the booking flow to a state we could defend in a procurement review, and as a first step the slot picker fixed properly — content descriptions, touch targets, focus order, the lot", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "the retry delays array in constants.ts goes 1s 2s 4s 8s but the client only ever reads the first two, wire the rest up", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "appointment reminders stopped going out saturday night, here's the sidekiq log around then:\n\n2026-07-25T22:58:01.114Z pid=41 tid=9x8 class=ReminderJob jid=8f2b1c INFO: start\n2026-07-25T22:58:01.882Z pid=41 tid=9x8 class=ReminderJob jid=8f2b1c INFO: 412 reminders queued\n2026-07-25T23:00:00.004Z pid=41 tid=a02 class=ReminderJob jid=91cc40 INFO: start\n2026-07-25T23:00:00.119Z pid=41 tid=a02 class=ReminderJob jid=91cc40 INFO: 0 reminders queued\n2026-07-25T23:02:00.006Z pid=41 tid=b71 class=ReminderJob jid=aa1902 INFO: start\n2026-07-25T23:02:00.101Z pid=41 tid=b71 class=ReminderJob jid=aa1902 INFO: 0 reminders queued\n2026-07-26T00:00:00.008Z pid=41 tid=c19 class=ReminderJob jid=bb7711 INFO: start\n2026-07-26T00:00:00.093Z pid=41 tid=c19 class=ReminderJob jid=bb7711 INFO: 0 reminders queued\n\nno errors, it just decided there was nothing to send", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "we need the waitlist offer job written, here's what product agreed to:\n\n- triggered when an appointment is cancelled or a slot opens through a reschedule\n- eligible entries: same clinic, same day, provider matches or the entry says \"any\", not expired, not already holding an offer\n- FIFO by created_at, one offer at a time, 2-hour acceptance window (configurable per clinic)\n- offer goes out on the patient's preferred channel; if that channel fails, fall back to the other and record it\n- if the window passes, the offer moves to the next eligible entry automatically\n- if nobody accepts within 24 hours, the slot goes back to normal availability and we stop\n- everything must survive a redeploy mid-window\n\nrails, sidekiq, postgres — same patterns as the reminder job", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "a mid-size clinic reported that dragging an appointment to a new time occasionally moves a different appointment instead, maybe once a day, and we have no way to reproduce it. the drag layer keys blocks by index in some places and by id in others, which smells, but i can't connect that to what they're seeing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our error codes are documented nowhere and support guesses; produce the table from `app/errors/` with a human explanation per code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "the endpoint for cancelling an appointment takes a reason enum that the mobile app doesn't send, so 40% of cancellations are `unspecified`, and product wants that fixed properly rather than defaulted", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "we have to support double-booking because three of our five pilot clinics deliberately overbook for no-show buffer, and our model currently forbids overlapping appointments at the database level with an exclusion constraint. i need to know what changes, how the schedule screen renders it, what the API says when someone books into an occupied slot, and how we let clinics that hate the idea keep the current behaviour", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "appointment blocks on the week grid are laid out with absolute positioning and magic offsets, so on a 13-inch laptop the 8am row is cut off and on a 4k monitor there's a band of dead space at the bottom. make the grid size to the viewport properly, keeping the existing look at the default zoom", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "compose theme file, inherited from a contractor. before i extend it for the dark palette i want to know what i'm dealing with:\n\n@Composable\nfun ClinicalTheme(\n darkTheme: Boolean = isSystemInDarkTheme(),\n dynamicColor: Boolean = true,\n content: @Composable () -> Unit\n) {\n val colorScheme = when {\n dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {\n val ctx = LocalContext.current\n if (darkTheme) dynamicDarkColorScheme(ctx) else dynamicLightColorScheme(ctx)\n }\n darkTheme -> DarkColors\n else -> LightColors\n }\n val view = LocalView.current\n if (!view.isInEditMode) {\n SideEffect {\n val window = (view.context as Activity).window\n window.statusBarColor = colorScheme.primary.toArgb()\n WindowCompat.getInsetsController(window, view).isAppearanceLightStatusBars = !darkTheme\n }\n }\n MaterialTheme(colorScheme = colorScheme, typography = ClinicalType, content = content)\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "unity console after the build, the frame time doubled and i think one of these is the culprit:\n\n[Profiler] PlayerLoop 33.4ms\n ├ Update.ScriptRunBehaviourUpdate 21.8ms\n │ ├ EnemySpawner.Update() 14.2ms (GC.Alloc 1.4 MB)\n │ ├ PathfindingManager.Update() 5.1ms\n │ └ HUDController.Update() 2.4ms (GC.Alloc 220 KB)\n ├ PreLateUpdate.DirectorUpdate 3.1ms\n └ Render.OpaqueGeometry 7.6ms\n\nWarning: Instantiating 'Bullet(Clone)' 240 times this frame\nWarning: GameObject.FindWithTag called from EnemySpawner.Update()\nWarning: Camera.main accessed 240 times this frame\n[GC] Incremental GC collected 3.2 MB in 8.1ms", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "play console ANR cluster from last week's release, 0.9% of sessions:\n\nANR in io.clinicly.app (io.clinicly.app/.MainActivity)\nPID: 4471\nReason: Input dispatching timed out (Application does not respond)\n\n\"main\" prio=5 tid=1 Blocked\n | group=\"main\" sCount=1 dsCount=0 flags=1 obj=0x72b9c4d0\n at io.clinicly.data.SyncCoordinator.awaitIdle(SyncCoordinator.kt:88)\n - waiting to lock <0x0a11c3f2> (a java.lang.Object) held by thread 42\n at io.clinicly.data.AppointmentRepository.refresh(AppointmentRepository.kt:214)\n at io.clinicly.ui.ScheduleViewModel$load$1.invokeSuspend(ScheduleViewModel.kt:66)\n\n\"DefaultDispatcher-worker-3\" prio=5 tid=42 Native\n at android.database.sqlite.SQLiteConnection.nativeExecuteForChangedRowCount(Native method)\n at io.clinicly.data.local.AppointmentDao_Impl.upsertAll(AppointmentDao_Impl.java:181)\n\nlocked <0x0a11c3f2>", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "sentry issue, been firing since the timezone work went in:\n\nActiveRecord::StatementInvalid: PG::DatetimeFieldOverflow: ERROR: date/time field value out of range: \"2026-11-01 02:30:00\"\nHINT: Perhaps you need a different \"datestyle\" setting.\n\n app/models/clinic_hours.rb:41:in `slots_for'\n app/services/appointments/availability.rb:88:in `block in build'\n app/services/appointments/availability.rb:84:in `each'\n app/services/appointments/availability.rb:84:in `build'\n app/controllers/api/v2/availability_controller.rb:19:in `index'\n\n clinic_id: 4412 (America/Santiago)\n requested_date: 2026-11-01\n events: 1,204 in 6 days\n users affected: 38\n\nonly clinics in a handful of timezones, and always on specific dates", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "gradle keeps failing on CI only, works on my machine and on two other laptops:\n\n> Task :app:kaptGenerateStubsReleaseKotlin FAILED\ne: file:///home/runner/work/clinicly/app/src/main/java/io/clinicly/di/AppModule.kt:44:1 error: [Dagger/DuplicateBindings] io.clinicly.data.Clock is bound multiple times:\n @Provides @Singleton io.clinicly.data.Clock io.clinicly.di.AppModule.provideClock()\n @Provides @Singleton io.clinicly.data.Clock io.clinicly.di.TestClockModule.provideClock()\n\nFAILURE: Build failed with an exception.\n* What went wrong:\nExecution failed for task ':app:kaptGenerateStubsReleaseKotlin'.\n> A failure occurred while executing org.jetbrains.kotlin.gradle.internal.KaptExecution\n\n* Try:\n> Run with --stacktrace option to get the stack trace.\n\nBUILD FAILED in 4m 12s", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "PR i'm meant to approve today. it's from someone senior so i want a second opinion before i comment:\n\n@@ -12,6 +12,28 @@ class Appointment < ApplicationRecord\n belongs_to :clinic\n belongs_to :patient\n \n+ after_commit :sync_to_calendar, on: [:create, :update]\n+\n+ def sync_to_calendar\n+ CalendarSyncJob.perform_now(id)\n+ rescue => e\n+ Rails.logger.warn(\"calendar sync failed: #{e.message}\")\n+ end\n+\n+ def self.overlapping(clinic_id, range)\n+ where(clinic_id: clinic_id)\n+ .where(\"tstzrange(starts_at, ends_at) && tstzrange(?, ?)\", range.first, range.last)\n+ end\n+\n scope :upcoming, -> { where(\"starts_at > ?\", Time.current) }\n@@ -41,7 +63,7 @@ class Appointment < ApplicationRecord\n- validates :starts_at, presence: true\n+ validates :starts_at, presence: true, if: -> { !skip_validation }", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "das ist unsere Migration für die Mandantentrennung. Bevor wir sie ausführen: hältst du das für sicher?\n\nclass AddClinicScopeToAppointments < ActiveRecord::Migration[7.1]\n def change\n add_column :appointments, :clinic_id, :bigint\n add_index :appointments, :clinic_id, algorithm: :concurrently\n Appointment.reset_column_information\n Appointment.find_each do |a|\n a.update_column(:clinic_id, a.patient.clinic_id)\n end\n change_column_null :appointments, :clinic_id, false\n add_foreign_key :appointments, :clinics\n end\nend\n\nTabelle hat 22 Millionen Zeilen, Postgres 16, kein Wartungsfenster", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "changelog time, we ship the android app thursday. commits since 3.4:\n\n* a81f22c feat(schedule): week view swipe gestures\n* 4409ba1 fix(sync): don't drop local edits when the server 409s\n* 77c0e19 fix(a11y): talkback reads slot times correctly now\n* 2b1904d chore: bump compose bom to 2026.06.00\n* 9911aa0 feat(booking): waitlist join from a full day\n* 31de770 perf(schedule): remove recomposition storm on day change\n* cc4102b fix(notifications): reminder deep link opened the wrong appointment\n* 6f2b901 chore: crashlytics ndk symbols upload\n* 0091ac4 fix(login): biometric prompt dismissed on first launch\n\nplay store listing, so friendly and short, no commit hashes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "support macro draft below is terrible and i have to send something today. rewrite it:\n\n\"Hi, Thank you for contacting Clinicly Support. Regarding your issue with appointment reminders not being sent, this is caused by the clinic timezone setting being incorrect in your Clinic Settings page which needs to be set correctly by an administrator of your clinic account. Please navigate to Settings > Clinic > Regional and select the correct timezone from the dropdown list and then save the changes and reminders will be sent correctly going forward. Note that appointments already scheduled will not be updated retroactively. Thank you for your patience. Best regards, Clinicly Support Team\"\n\nkeep the facts, lose the bureaucracy, and add the bit about existing appointments needing a manual resend", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "app crashes on API 34 the moment you open notifications settings, and the fix is probably one line:\n\njava.lang.SecurityException: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts\n\tat android.os.Parcel.createExceptionOrNull(Parcel.java:3057)\n\tat android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1826)\n\tat io.clinicly.notifications.ReminderSettingsFragment.onStart(ReminderSettingsFragment.kt:44)\n\ntargetSdk went from 33 to 34 in the last release", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "HUD prefab is a mess of anchors and i've been asked to make it work on ultrawide and on steam deck. current layout values:\n\nCanvas: Scale With Screen Size, ref 1920x1080, match 0.5\nHealthBar: anchor min (0,1) max (0,1), pos (120, -60), size (240, 24)\nAmmoCounter: anchor min (1,1) max (1,1), pos (-140, -60), size (180, 40)\nMinimap: anchor min (1,0) max (1,0), pos (-160, 160), size (280, 280)\nWaveBanner: anchor min (0.5,1) max (0.5,1), pos (0, -40), size (600, 80)\nBossHealth: anchor min (0.5,1) max (0.5,1), pos (0, -140), size (900, 32)\n\nat 21:9 the minimap sits under the bezel on deck and the boss bar overlaps the wave banner", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "clinic phone number missing from the receipt", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "waitlist window default to 90 minutes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "one slot-eligibility function, not three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "kdoc on SyncCoordinator, please", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "is our tenant scoping actually enforced?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "schedule thing again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "there is no document anywhere that says what happens to a patient's data when a clinic leaves us, and both legal and two prospects have now asked. from the code and the ops runbooks, work out what actually happens today — export format, deletion timeline, what stays in backups — and write it up as a page we can hand to a customer without lawyering it first", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand how room assignment picks a room when two appointments could use the same one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "compose app is one gradle module and builds take four minutes on the CI runners, which is starting to hurt. modularising is the obvious answer but i've seen it go badly — circular dependencies, dagger components everywhere, nobody agreeing where things live. what would a sane module structure look like for an app this size, and in what order would you carve it up", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "logcat from a tester's Pixel, the appointment list just goes blank:\n\nE/AndroidRuntime( 8812): FATAL EXCEPTION: main\nE/AndroidRuntime( 8812): Process: io.clinicly.app, PID: 8812\nE/AndroidRuntime( 8812): java.lang.IllegalStateException: Reading a state that was created after the snapshot was taken or in a snapshot that has not yet been applied\nE/AndroidRuntime( 8812): \tat androidx.compose.runtime.snapshots.SnapshotKt.readError(Snapshot.kt:2371)\nE/AndroidRuntime( 8812): \tat androidx.compose.runtime.snapshots.SnapshotStateList.get(SnapshotStateList.kt:88)\nE/AndroidRuntime( 8812): \tat io.clinicly.schedule.DayColumnKt$DayColumn$1$2.invoke(DayColumn.kt:141)\nE/AndroidRuntime( 8812): \tat androidx.compose.foundation.lazy.LazyListKt.items(LazyList.kt:212)\nE/AndroidRuntime( 8812): \tat io.clinicly.schedule.ScheduleScreenKt.ScheduleScreen(ScheduleScreen.kt:88)\nE/AndroidRuntime( 8812): \tat io.clinicly.MainActivity$onCreate$1.invoke(MainActivity.kt:52)\n\nonly reproduces after you rotate while the refresh is in flight", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "rspec is red on main and the diff that broke it is three commits back somewhere:\n\nFailures:\n\n 1) Appointments::Reschedule moves the slot and notifies the patient\n Failure/Error: expect(appointment.reload.starts_at).to eq(new_slot.starts_at)\n\n expected: 2026-08-03 14:00:00.000000000 +0000\n got: 2026-08-03 13:00:00.000000000 +0000\n\n (compared using ==)\n # ./spec/services/appointments/reschedule_spec.rb:41:in `block (2 levels)'\n\n 2) Appointments::Reschedule refuses a slot outside clinic hours\n Failure/Error: expect { subject }.to raise_error(OutsideClinicHours)\n expected OutsideClinicHours, got #<ActiveRecord::RecordInvalid: Validation failed: Starts at must be in the future>\n # ./spec/services/appointments/reschedule_spec.rb:63:in `block (2 levels)'\n\nFinished in 1 minute 12.4 seconds (files took 6.1 seconds to load)\n412 examples, 2 failures\n\nboth of these passed on friday and nobody touched the scheduler", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ログにこれが延々と出ていて、予約の同期が止まります。原因が分かりません:\n\nW/SyncWorker(3312): retrying sync attempt=4 delay=8000ms\nW/SyncWorker(3312): retrying sync attempt=5 delay=16000ms\nE/SyncWorker(3312): sync failed: retrofit2.HttpException: HTTP 409 Conflict\nE/SyncWorker(3312): \tat io.clinicly.net.ApiClient$sync$2.invokeSuspend(ApiClient.kt:141)\nE/SyncWorker(3312): \tat kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)\nI/WM-WorkerWrapper(3312): Worker result RETRY for Work [ id=8f21-c0aa-4771, tags={ sync } ]\nI/WM-Processor(3312): Processor stopping foreground work sync\nW/SyncWorker(3312): retrying sync attempt=6 delay=32000ms\n\nサーバー側のログでは 409 は「revision mismatch」と書いてあります", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "ja"}
{"prompt": "crash reporter groups these together but the stacks look unrelated to me:\n\nNullReferenceException: Object reference not set to an instance of an object\n at Clinicly.Game.WaveDirector.OnEnemyKilled (Clinicly.Game.Enemy e) [0x00021] in /Assets/Scripts/WaveDirector.cs:118\n at Clinicly.Game.Enemy.Die () [0x0000c] in /Assets/Scripts/Enemy.cs:88\n at Clinicly.Game.DamageSystem.Apply (Clinicly.Game.Enemy target, System.Single amount) [0x00044] in /Assets/Scripts/DamageSystem.cs:52\n at Clinicly.Game.Bullet.OnTriggerEnter (UnityEngine.Collider other) [0x0001a] in /Assets/Scripts/Bullet.cs:41\n\nMissingReferenceException: The object of type 'Transform' has been destroyed but you are still trying to access it.\n at UnityEngine.Transform.get_position ()\n at Clinicly.Game.HomingBullet.FixedUpdate () [0x00010] in /Assets/Scripts/HomingBullet.cs:33\n\n480 users, all on the wave-12 boss", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "detekt and the runtime disagree about this coroutine scope, and users see duplicate bookings:\n\nclass BookingViewModel(\n private val repo: AppointmentRepository,\n private val scope: CoroutineScope = CoroutineScope(SupervisorJob() + Dispatchers.Default)\n) : ViewModel() {\n\n fun book(slotId: String) {\n scope.launch {\n val result = repo.book(slotId)\n _state.update { it.copy(booked = result) }\n }\n }\n\n override fun onCleared() {\n super.onCleared()\n }\n}\n\ntapping book twice quickly creates two appointments about 30% of the time, and rotating the phone mid-book does it every time", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "security questionnaire from a hospital customer came back with this section and i need to answer honestly:\n\n7.3 — Does the application enforce role-based access control at the API layer, and are authorization decisions logged?\n7.4 — Are patient records segregated per tenant at the database level, and if so by what mechanism?\n7.5 — Describe session invalidation on password change and on administrative account suspension.\n7.6 — Are audit logs immutable and retained for at least six years?\n7.9 — Can a clinic administrator export all data for a single patient on request, and how long does that take?\n\ngo through our rails app and tell me what's actually true for each of these", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "someone's proposed this ECS refactor in the game repo and i can't tell if it's an improvement or just fashion:\n\n// current\npublic class Enemy : MonoBehaviour {\n public float speed; public int hp;\n void Update() { transform.position += dir * speed * Time.deltaTime; }\n}\n\n// proposed\npublic struct Position : IComponentData { public float3 Value; }\npublic struct Velocity : IComponentData { public float3 Value; }\npublic partial struct MoveSystem : ISystem {\n public void OnUpdate(ref SystemState state) {\n foreach (var (pos, vel) in SystemAPI.Query<RefRW<Position>, RefRO<Velocity>>())\n pos.ValueRW.Value += vel.ValueRO.Value * SystemAPI.Time.DeltaTime;\n }\n}\n\nwe have maybe 300 enemies on screen at peak and a two-person team", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility audit output for the booking flow, tell me which of these are real problems and which are the tool being pedantic:\n\nsrc/booking/SlotPicker.tsx\n serious Buttons must have discernible text (button-name) — 14 nodes\n serious Form elements must have labels (label) — 3 nodes\n moderate Elements must have sufficient color contrast (color-contrast) — 22 nodes (4.1:1 vs required 4.5:1)\n minor Heading levels should only increase by one (heading-order) — 2 nodes\n\nsrc/booking/Confirmation.tsx\n critical <html> element must have a lang attribute (html-has-lang)\n serious ARIA attributes must conform to valid values (aria-valid-attr-value) — aria-live=\"polite \" (trailing space)\n moderate Interactive controls must not be nested (nested-interactive) — 1 node\n\n47 total violations, 0 incomplete", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "here's the query the scheduling page runs every time someone changes the week. is 400ms reasonable for this or is something dumb happening?\n\nSELECT a.id, a.starts_at, a.ends_at, a.status,\n p.first_name, p.last_name, p.date_of_birth,\n pr.display_name AS provider_name,\n r.name AS room_name,\n (SELECT COUNT(*) FROM appointment_notes n WHERE n.appointment_id = a.id) AS note_count\nFROM appointments a\nJOIN patients p ON p.id = a.patient_id\nJOIN providers pr ON pr.id = a.provider_id\nLEFT JOIN rooms r ON r.id = a.room_id\nWHERE a.clinic_id = $1\n AND a.starts_at >= $2 AND a.starts_at < $3\n AND a.status <> 'cancelled'\nORDER BY a.starts_at ASC;\n\nindexes: appointments(clinic_id, starts_at), patients(id), providers(id)", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "two engineers wrote the same helper in the same sprint. which one would you keep, and why?\n\n// version A — utils/time.ts\nexport function slotsBetween(open: Date, close: Date, minutes: number): Date[] {\n const out: Date[] = []\n for (let t = open.getTime(); t + minutes * 60000 <= close.getTime(); t += minutes * 60000)\n out.push(new Date(t))\n return out\n}\n\n// version B — booking/slots.ts\nexport const buildSlots = ({ open, close, step, skip = [] }: SlotArgs) =>\n Array.from(\n { length: Math.floor((+close - +open) / (step * 60000)) },\n (_, i) => new Date(+open + i * step * 60000)\n ).filter(d => !skip.some(([s, e]) => d >= s && d < e))\n\nboth are used in production right now, on different screens", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "raw notes from the clinic onboarding call, turn them into the implementation guide we hand to new customers:\n\n- they get a CSV of patients from their old system, columns never match, we map by hand today\n- provider availability set up in the admin, but recurring blocks (lunch, admin time) are a separate screen nobody finds\n- rooms are optional; single-provider clinics skip them entirely\n- SMS reminders need their own twilio number, takes 2-3 days for approval, has to start before go-live\n- test appointment then a test reminder is how we prove it works\n- go-live is always a monday, they keep the old system read-only for a month\n- most common failure: nobody set the clinic timezone and every reminder goes out an hour off", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "api reference for the availability endpoint is one sentence long. here's the controller — write the real thing:\n\ndef index\n clinic = Clinic.find(params[:clinic_id])\n authorize! :read, clinic\n range = DateRange.parse!(params[:from], params[:to])\n raise TooWide if range.days > 62\n providers = clinic.providers.where(id: params[:provider_ids].presence || clinic.provider_ids)\n slots = Appointments::Availability.new(clinic:, providers:, range:, duration: params.fetch(:duration, 30).to_i).build\n render json: { data: slots.map { |s| SlotSerializer.new(s) }, meta: { timezone: clinic.timezone } }\nend\n\ncover the 30-day default, the 62-day cap, what duration does, and that all times come back in clinic-local ISO8601", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "escreve o texto do post-mortem a partir destas notas, formato: impacto, cronologia, causa, ações:\n\n14:02 — clientes reportam que a agenda aparece vazia\n14:06 — on-call confirma: API devolve 200 com lista vazia para clínicas com fuso -03\n14:11 — deploy das 13:40 identificado como suspeito (mudança no cálculo de intervalos)\n14:19 — rollback iniciado\n14:26 — rollback concluído, agendas voltam ao normal\n14:40 — confirmado: 61 clínicas afetadas durante 24 minutos, nenhuma consulta perdida\n15:10 — causa: o novo cálculo usava a data do servidor em UTC em vez do fuso da clínica\n\nações combinadas: teste de regressão com fusos negativos, alerta para respostas vazias acima de 5%", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "pt"}
{"prompt": "kotlin file has zero kdoc and the next person will hate us. document the public surface based on what it does:\n\nclass SyncCoordinator(\n private val api: ApiClient,\n private val dao: AppointmentDao,\n private val clock: Clock,\n) {\n suspend fun pull(since: Instant?): SyncResult { /* ... */ }\n suspend fun push(pending: List<PendingEdit>): SyncResult { /* ... */ }\n suspend fun awaitIdle(timeout: Duration = 30.seconds)\n fun observeState(): Flow<SyncState>\n val lastSuccessfulSync: Instant?\n}\n\nthings worth capturing: pull with a null `since` does a full refresh and can take minutes on a big clinic; push is all-or-nothing per batch; awaitIdle throws on timeout; observeState never completes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "i have to explain our offline behaviour to the app review team and to our own support staff. here's what the code does, in bullets, from my reading:\n\n- edits made offline go into a `pending_edits` room table with a local revision\n- on reconnect, push happens before pull, oldest first\n- a 409 from the server means the server version won, and the local edit is discarded silently\n- appointments created offline get a client-generated UUID that the server honours\n- if the app is killed mid-sync, the worker restarts the whole batch\n- there is no user-visible indication that a local edit was discarded\n\nturn that into two documents: one for the app review notes, one for support", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "README for the game repo hasn't been touched since the jam version. current state of things:\n\n- unity 6000.0.28f1, URP, addressables for the level packs\n- three scenes that matter: Boot, Hub, Run. everything else is test scaffolding\n- input via the new Input System, bindings in Assets/Settings/PlayerControls.inputactions\n- steam build via a bash script in tools/, needs SteamCMD on PATH and a `.env` with the app id\n- tests: EditMode only, playmode tests are broken and skipped in CI\n- known: opening Run directly from the editor bypasses save loading and softlocks after the first wave\n\nwrite it so a new contributor can get to a running build without asking anyone", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "ktlint is blocking the merge, all of it looks cosmetic:\n\napp/src/main/java/io/clinicly/ui/ScheduleScreen.kt:41:1: Wildcard import (cannot be auto-corrected)\napp/src/main/java/io/clinicly/ui/ScheduleScreen.kt:88:121: Exceeded max line length (120)\napp/src/main/java/io/clinicly/ui/ScheduleScreen.kt:141:5: Missing newline before \"}\"\napp/src/main/java/io/clinicly/data/SyncCoordinator.kt:19:1: Package name must not contain underscore\napp/src/main/java/io/clinicly/data/SyncCoordinator.kt:66:33: Unnecessary semicolon\napp/src/main/java/io/clinicly/di/AppModule.kt:12:1: Imports must be ordered in lexicographic order\n\n> Task :app:ktlintMainSourceSetCheck FAILED\n6 style violations", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "pasted-context", "lang": "en"}
{"prompt": "rubocop after the rebase, just get it green:\n\nOffenses:\n\napp/services/appointments/availability.rb:14:5: C: Metrics/MethodLength: Method has too many lines. [22/15]\napp/services/appointments/availability.rb:41:81: C: Layout/LineLength: Line is too long. [104/100]\napp/services/appointments/reschedule.rb:9:3: C: Style/Documentation: Missing top-level class documentation comment.\napp/models/clinic_hours.rb:33:11: W: Lint/UselessAssignment: Useless assignment to variable - `tz`.\napp/controllers/api/v2/availability_controller.rb:22:7: C: Style/GuardClause: Use a guard clause instead of wrapping the code inside a conditional expression.\nspec/factories/appointments.rb:5:1: C: Naming/VariableNumber: Use normalcase for symbol numbers.\n\n612 files inspected, 6 offenses detected, 3 offenses auto-correctable", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependency check flagged these in the rails app, pick the ones we should just bump today:\n\nName: nokogiri\nVersion: 1.16.2\nAdvisory: CVE-2026-11221\nCriticality: High\nSolution: upgrade to '>= 1.17.1'\n\nName: rack\nVersion: 3.0.9\nAdvisory: CVE-2026-10884\nCriticality: Medium\nTitle: Possible ReDoS in Rack::Request header parsing\nSolution: upgrade to '>= 3.0.11'\n\nName: image_processing\nVersion: 1.12.2\nAdvisory: GHSA-7x2f-9k1c\nCriticality: Low\nSolution: upgrade to '>= 1.13.0'\n\nVulnerabilities found!", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "tsc is unhappy after the react 19 bump, and i think these are all the same mistake repeated:\n\nsrc/booking/SlotPicker.tsx:44:7 - error TS2322: Type '{ children: Element; ref: MutableRefObject<HTMLDivElement | null>; }' is not assignable to type 'IntrinsicAttributes & SlotGridProps'.\n Property 'ref' does not exist on type 'IntrinsicAttributes & SlotGridProps'.\n\nsrc/booking/Confirmation.tsx:19:23 - error TS2769: No overload matches this call.\n Argument of type '(e: React.FormEvent) => Promise<void>' is not assignable to parameter of type 'FormEventHandler<HTMLFormElement>'.\n\nsrc/schedule/WeekGrid.tsx:88:11 - error TS2339: Property 'defaultProps' does not exist on type 'FunctionComponent<WeekGridProps>'.\n\nFound 3 errors in 3 files.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "a short note for the team explaining why we moved reminders off after_commit, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "our repository interfaces return `Result<T>` in some places and throw in others; pick one and apply it, no behaviour change at the UI layer", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "the usual pre-release pass, you know the drill", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "appointment types are hardcoded as an enum in three languages: a rails enum, a kotlin sealed class, and a typescript union that's already out of date. how would you like to see this owned in one place? tell me the approach and then do the rails side", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "we keep telling customers that appointment data syncs \"in near real time\" and i genuinely don't know if that's true anymore given the worker changes. read the sync path, work out what the actual guarantees are — latency, ordering, what happens on conflict — and write the honest version for the docs site, including the caveats we'd rather not advertise", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "a migration note for integrators about the v2 availability response shape, they need to know about the `meta.timezone` field", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "our CI runs the android lint task twice, once in the check job and once in the release job, drop one", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "the compose theme file came from a contractor and i've been told it's \"basically standard\" three times by people who haven't opened it. i'd like an actual assessment against how material 3 expects to be set up, particularly the dynamic colour branch and the status bar side effect, before i add a dark palette on top of it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "we owe the partner an eligibility-check endpoint on our side by the end of the month: they call us with a patient reference and a payer id, we look up the patient, hit their sandbox, cache the answer for an hour, and return a normalised status. rate limit is 5 rps on their side and they penalise us for exceeding it", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "appointment durations over 4 hours render as a block with no end time, clamp it or show the end explicitly", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "config drift between the two staging clinics, one of them sends reminders at the wrong hour:\n\n# clinic 4412 (settings.yml)\nreminder_lead_hours: 24\nreminder_send_window: \"08:00-20:00\"\ntimezone: \"America/Santiago\"\nsms_enabled: true\nemail_enabled: true\nwaitlist_offer_window_minutes: 120\ndouble_booking_allowed: false\nslot_minutes: 30\n\n# clinic 4419 (settings.yml)\nreminder_lead_hours: 24\nreminder_send_window: \"08:00-20:00\"\ntimezone: \"UTC\"\nsms_enabled: true\nemail_enabled: false\nwaitlist_offer_window_minutes: 120\ndouble_booking_allowed: false\nslot_minutes: 15\n\n# production template both were cloned from\nreminder_lead_hours: 24\nreminder_send_window: \"08:00-20:00\"\ntimezone: null # must be set per clinic on creation\nsms_enabled: true\nemail_enabled: true\nwaitlist_offer_window_minutes: 120\ndouble_booking_allowed: false\nslot_minutes: 30\n\nboth were meant to be copies of that template and neither matches it", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "unity throws this every time the level loads and it's just noise in the console but it's hiding real errors:\n\nAssets/Scripts/UI/HUDController.cs(41,17): warning CS0618: 'Object.FindObjectOfType<T>()' is obsolete: 'Object.FindObjectOfType has been deprecated. Use Object.FindFirstObjectByType instead or if finding any instance is acceptable the faster Object.FindAnyObjectByType'\nAssets/Scripts/WaveDirector.cs(88,9): warning CS0618: same\nAssets/Scripts/Audio/MusicManager.cs(22,13): warning CS0618: same\nAssets/Scripts/Save/SaveSystem.cs(112,21): warning CS0672: 'SaveSystem.Serialize(Stream)' overrides obsolete member\n\n41 warnings total, 12 of them this one", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "esta función se repite en tres pantallas casi igual. quiero una sola versión, sin cambiar el comportamiento:\n\n// SlotPicker.tsx\nconst isBookable = (s: Slot) =>\n !s.taken && s.startsAt > new Date() && !s.blocked && s.providerId === selectedProvider\n\n// WeekGrid.tsx\nfunction bookable(slot) {\n if (slot.taken) return false\n if (slot.blocked) return false\n if (new Date(slot.startsAt) <= new Date()) return false\n return !provider || slot.providerId === provider\n}\n\n// WaitlistSheet.tsx\nconst canOffer = (slot: Slot, providerId?: string) =>\n [!slot.taken, !slot.blocked, +new Date(slot.startsAt) > Date.now(),\n providerId ? slot.providerId === providerId : true].every(Boolean)", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "es"}
{"prompt": "this composable has grown a fifth responsibility and i want it split without changing a pixel:\n\n@Composable\nfun ScheduleScreen(vm: ScheduleViewModel = hiltViewModel()) {\n val state by vm.state.collectAsStateWithLifecycle()\n val snackbar = remember { SnackbarHostState() }\n LaunchedEffect(state.error) { state.error?.let { snackbar.showSnackbar(it) } }\n LaunchedEffect(Unit) { vm.trackScreenView() }\n Scaffold(\n topBar = { /* 40 lines of week picker, provider filter and overflow menu */ },\n snackbarHost = { SnackbarHost(snackbar) },\n floatingActionButton = { /* 20 lines with three conditional states */ },\n ) { padding ->\n when {\n state.loading -> ShimmerGrid(padding)\n state.days.isEmpty() -> EmptyDay(padding, onRefresh = vm::refresh)\n else -> /* 90 lines of day columns, drag-to-reschedule and overlap layout */\n }\n }\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "service object that grew organically. same behaviour, better seams, and it needs to stay callable from the controller exactly as it is:\n\nclass Appointments::Reschedule\n def initialize(appointment, new_slot, actor:, notify: true, skip_validation: false)\n @appointment = appointment; @new_slot = new_slot; @actor = actor\n @notify = notify; @skip_validation = skip_validation\n end\n\n def call\n raise OutsideClinicHours unless @skip_validation || within_hours?\n raise SlotTaken if Appointment.overlapping(@appointment.clinic_id, @new_slot.range).where.not(id: @appointment.id).exists?\n ActiveRecord::Base.transaction do\n @appointment.update!(starts_at: @new_slot.starts_at, ends_at: @new_slot.ends_at)\n AuditLog.create!(actor: @actor, action: \"reschedule\", subject: @appointment)\n CalendarSyncJob.perform_later(@appointment.id)\n PatientMailer.rescheduled(@appointment).deliver_later if @notify\n SmsSender.new(@appointment.patient).rescheduled(@appointment) if @notify && sms?\n end\n @appointment\n end\nend", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "four scripts in the unity project all reach for the player the same way. i want one accessor and no behaviour change:\n\n// WaveDirector.cs\nvar player = GameObject.FindWithTag(\"Player\").GetComponent<PlayerController>();\n\n// HomingBullet.cs\nvar player = GameObject.Find(\"Player\").transform;\n\n// HUDController.cs\nPlayerController player = FindObjectOfType<PlayerController>();\n\n// SaveSystem.cs\nvar player = GameObject.FindGameObjectsWithTag(\"Player\").FirstOrDefault()?.GetComponent<PlayerController>();\n\nall four are called from Update or from OnEnable, some of them every frame", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "test suite has this shape repeated 60-odd times and it's why nobody adds tests:\n\nRSpec.describe Appointments::Availability do\n let(:clinic) { create(:clinic, timezone: \"America/New_York\") }\n let(:provider) { create(:provider, clinic: clinic) }\n let!(:hours) { create(:clinic_hours, clinic: clinic, weekday: 1, opens_at: \"09:00\", closes_at: \"17:00\") }\n let(:range) { Date.new(2026, 8, 3)..Date.new(2026, 8, 3) }\n\n before do\n travel_to Time.zone.parse(\"2026-08-01 08:00\")\n allow(FeatureFlags).to receive(:enabled?).with(:waitlist).and_return(false)\n end\n\n after { travel_back }\n # ... 8 examples\nend\n\nsame five let blocks, same travel_to, same flag stub, in every scheduling spec", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "navigation in the app is half compose-navigation and half fragments, this is the current graph plus the leftovers:\n\nNavHost(navController, startDestination = \"schedule\") {\n composable(\"schedule\") { ScheduleScreen() }\n composable(\"booking/{slotId}\") { BookingScreen(it.arguments?.getString(\"slotId\")!!) }\n composable(\"patient/{id}\") { PatientScreen(it.arguments?.getString(\"id\")!!) }\n activity(\"legacy_settings\") { activityClass = SettingsActivity::class }\n}\n\n// still around\nclass PatientListFragment : Fragment() // reached from SettingsActivity\nclass ProviderPickerFragment : DialogFragment() // shown from ScheduleScreen via FragmentManager\nclass OnboardingActivity : AppCompatActivity() // launched from MainActivity.onCreate\n\nthe hybrid is why back handling is inconsistent. same destinations, one mechanism", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "un fichier de constantes qui a mal vieilli, je veux le réorganiser sans rien casser :\n\n// constants.ts\nexport const SLOT_MINUTES = 30\nexport const MAX_RANGE_DAYS = 62\nexport const API_BASE = process.env.NEXT_PUBLIC_API ?? \"https://api.clinicly.io\"\nexport const COLORS = { booked: \"#2f6fed\", blocked: \"#9aa0a6\", free: \"#ffffff\" }\nexport const REMINDER_LEAD_HOURS = 24\nexport const WAITLIST_WINDOW_MIN = 120\nexport const FEATURE_WAITLIST = true\nexport const DATE_FMT = \"yyyy-MM-dd\"\nexport const TZ_FALLBACK = \"UTC\"\nexport const SUPPORT_EMAIL = \"[email protected]\"\nexport const RETRY_DELAYS = [1000, 2000, 4000, 8000]\nexport const LEGACY_SLOT_MINUTES = 15 // still used by the old week grid\n\nimporté par 41 fichiers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "fr"}
{"prompt": "discovery notes from the clinic visits last week. i need this turned into a roadmap with phases, not a feature list:\n\n- front desk staff use paper for the waitlist because the digital one takes too many taps\n- three of five clinics double-book deliberately for no-show buffer; our model forbids it\n- providers want to see their own day on a phone, receptionists want the whole clinic on a monitor\n- nobody uses the reporting screen; two clinics export to excel weekly instead\n- the biggest complaint is that cancelling requires four confirmations\n- one clinic runs two locations from one account and it half-works\n- insurance eligibility check is done outside our system entirely, on a separate portal", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "leadership handed down this constraint set for the mobile rewrite and i need a realistic sequencing before we commit to dates:\n\n- android and ios must ship the same features at the same time from Q4\n- the current android app is kotlin/compose, ios is a webview wrapper nobody maintains\n- team is four android engineers, one ios contractor starting in september\n- offline support is non-negotiable for both, clinics have bad wifi\n- the design system exists in figma but only android components are built\n- there is a hard deadline: a customer conference in march where both must demo\n- we cannot stop shipping android features in the meantime", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "game's save system is about to become a problem and i'd rather design now than patch later. current state:\n\n- SaveSystem.cs writes a JSON blob to Application.persistentDataPath every checkpoint\n- no versioning; loading an old save from before the wave rework silently zeroes progress\n- cloud saves via steam are on the roadmap for the 1.0 release\n- players have already reported losing runs when the game is force-quit mid-write\n- we want a run history screen eventually, which means multiple saves, not one blob\n\nwhat should the shape of this be, and what's the migration path for saves already in the wild", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "compliance ticket landed and i don't want to start coding before we agree the shape:\n\nCOMP-118 — Audit trail for patient record access\nEvery read of a patient record must be recorded: who, when, which record, from which client, and the stated reason where one is required. Records must be queryable by patient (for subject access requests) and by user (for internal investigations). Retention six years, tamper-evident. Must not measurably slow the schedule screen, which reads dozens of patient summaries per page load. Applies to API, admin panel and the mobile apps. Existing access is not backfilled.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "figma redlines for the new day column, build it in compose:\n\nDay column (phone, 360dp)\n- Header: weekday abbrev (labelMedium) over day number (headlineSmall). Today: number in a 32dp filled circle, onPrimary text.\n- Hour rows 64dp tall, 1dp divider at 12% onSurface. Half-hour: dotted divider, 6% opacity.\n- Appointment block: 8dp corner, 4dp inset from the column edges, 3dp leading accent bar coloured by appointment type. Title bodyMedium truncated to one line; patient name bodySmall, 70% alpha.\n- Overlaps: split the column evenly, 2dp gutter, max three side by side, then \"+N\" chip on the third.\n- Now line: 2dp accent, dot at the leading edge, only shown for today.\n- Drag to reschedule: block lifts 4dp with shadow, snaps to 15-minute steps, target row highlighted at 8% accent.\n- Empty state: centred \"Nothing booked\" bodyMedium at 50% alpha.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ticket with the designer's notes attached, the waitlist sheet on web:\n\nWaitlist sheet (desktop modal, 480px)\n- Title \"Join the waitlist\" (20px semibold), subtitle with the chosen day in long form.\n- Provider select: our existing Select component, defaults to \"Any provider\", shows avatars.\n- Time-of-day preference: three toggle chips (Morning / Afternoon / Any), single select, \"Any\" default.\n- Contact preference: radio group, SMS / Email, prefilled from the patient record, with the masked contact shown next to each.\n- Footnote in 12px muted: \"We'll hold your spot for 2 hours once we offer it.\"\n- Primary \"Join waitlist\", secondary \"Cancel\". Primary disabled while submitting, spinner inside the button.\n- On success the modal is replaced in place by a confirmation state with a checkmark, no navigation.\n- Errors render above the buttons in a red inline alert, never a toast.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "这是设计稿标注，帮我把预约确认页写出来（React + Tailwind）：\n\n确认页（移动端 375px）\n- 顶部：诊所名称 16px 中等字重，下面是地址 13px 灰色，右侧是地图图标按钮 40x40。\n- 主卡片：圆角 12px，1px 边框，内边距 16px。第一行日期 20px 半粗，第二行时间段 15px。\n- 医生一行：32px 头像 + 姓名 + 科室，中间用 8px 间距。\n- 提醒开关：默认开启，副标题写「就诊前 24 小时短信提醒」。\n- 底部按钮：主按钮「确认预约」占满宽度 48px 高，次要按钮「取消」文字按钮。\n- 加载中：主按钮内显示 spinner，其余内容保持不动。\n- 出错时在按钮上方显示红色提示条，不要弹窗。", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "zh"}
{"prompt": "spec from the integration partner, build our side of it:\n\nPOST /v2/webhooks/eligibility\n headers: X-Partner-Signature (HMAC-SHA256 of the raw body, secret per partner), X-Partner-Id\n body: { request_id, patient_ref, payer_id, status: \"active\"|\"inactive\"|\"unknown\", copay_cents?, checked_at }\n we must respond 200 within 3 seconds or they retry with the same request_id for 24 hours\n duplicate request_id must be a no-op that still returns 200\n unknown patient_ref: respond 200 and record it, do not 404 (they treat 4xx as a hard failure and disable the hook)\n signature mismatch: 401, and we should alert\n they send roughly 40k of these a day, bursty around 06:00 clinic-local", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "reminder lead time to 48h", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "versionCode wasn't bumped for the hotfix", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "\"appointement\" in the confirmation email", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "proguard rule for the analytics SDK", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "strip the debug toast from BookingScreen", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "en"}
{"prompt": "sentry DSN is still the staging one", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "delete the dead `LEGACY_SLOT_MINUTES`", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "el copy del botón dice «Reservar», debería ser «Confirmar»", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "es"}
{"prompt": "nokogiri to 1.17.1 please", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "turn off dynamicColor for now", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "today's date needs a filled circle", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "pull-to-refresh on the day view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "provider avatars in the week header", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "minimap clips on ultrawide", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "empty day needs an illustration", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "ボタンのタップ領域が小さすぎます", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "ja"}
{"prompt": "cancel confirmation should be one tap", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "slot chips wrap badly at 320dp", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "now-line should be accent, not red", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "HUD scale is wrong on deck", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "`ApptSvc` should read `AppointmentService`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "lift the week picker out of ScheduleScreen", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "die Konstanten nach Bereichen gruppieren", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "de"}
{"prompt": "a nightly job that flags appointments whose provider no longer works at the clinic, so front desk can reassign them before the patient turns up", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "our staging data is a six-month-old production dump with names scrambled, which is why timezone bugs never show up before release. what should the test data story actually be", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "the changelog for the android app has been \"bug fixes and improvements\" for six releases, which is embarrassing given how much has actually changed. go through the commits since 3.0, write proper release notes for each version, and while you're in there fix the two entries in the existing changelog that describe features we cut", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.4, "slice": "mixed", "lang": "en"}
{"prompt": "collapse the two slot builders", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "`starts_at` naming, consistent everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "shared rspec context for scheduling specs", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "one player accessor for all scripts", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "inline `bookable`, it's used once", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "play store release notes, friendly tone", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "changelog entry for the waitlist", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "kurze Doku für den Reminder-Job", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
{"prompt": "summarise `Availability#build` for the wiki", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the ANR fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "where does `skip_validation` come from?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "¿qué hace exactamente `SyncCoordinator.pull`?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "es"}
{"prompt": "which of these two helpers is safer?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the offer job", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "any reason `after_commit` fires twice here?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "reminders went out an hour early", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "week view flickers on day change", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "booking twice creates two appointments", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "le calendrier reste vide après le login", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "fr"}
{"prompt": "soft-delete on appointments, rails side", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "plan the audit trail, then build phase one", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "scope the ios rewrite, then start the shell", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "same as yesterday", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "clean this up", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "go ahead with the waitlist", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "nicer", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "onboarding, but properly this time", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "weiter wie besprochen", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "de"}
{"prompt": "you know what to do", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "できるところまでお願いします", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "ja"}
{"prompt": "round two on the sync", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "make the wave feel meaner", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "do the needful on scheduling", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidy the theme file", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "o de sempre, mas para a agenda", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "pt"}
{"prompt": "clinics with two locations are running on one account and it half works today: shared provider list, shared patient records, but the schedule screen can only show one location's rooms at a time and reminders always use the first location's address. before we build multi-location properly i want to know whether that's a data model change or a permissions change, and what it does to every clinic already on the platform", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "insurance eligibility is checked on a separate portal today and front desk staff retype the result into a note. bringing it in-house means a partner API, PHI leaving our boundary in a new direction, and a support burden when the payer is down. i'd like the options laid out — full integration, deep link with prefill, or nothing — with what each costs us over a year", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "game needs a difficulty curve that isn't just hp multipliers and i keep going back and forth. we have wave composition, enemy stats, spawn rate, arena hazards and drop rates as knobs, plus a run-length target of about 25 minutes. sketch out how you'd structure the tuning so a designer can iterate without touching code, and what we'd need to log to know whether it's working", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "hospital group wants us on their infrastructure rather than our cloud, which we have never done. that means a deployment story, a licence story, an upgrade story and a support story, none of which exist. i want the shape of what we'd have to build and what we'd have to say no to, before sales promises anything in the next call", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "clinic staff turnover is high and every new receptionist gets trained by the last one, which is why nobody knows about half the features. i'd like a proper training guide: the daily workflow start to finish, the five things that go wrong most often and how to fix them, and a one-page cheat sheet they can print and stick on the monitor", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "android release process lives in one engineer's head: which branch, when to bump versionCode, the staged rollout percentages, when to promote, what to do when crashlytics spikes mid-rollout, and how to halt. write it down as a runbook that someone else could follow on a wednesday afternoon without asking them anything", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "steam page copy is three sentences and reads like a placeholder because it is one. the game is a roguelike with a clinic aesthetic, run-based, 25-minute runs, deck-of-treatments mechanic. write the store description, the short blurb, and the five bullet features, in a voice that isn't every other roguelike page", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "reading `Appointments::Availability` end to end took me an hour and i still couldn't tell you why the 62-day cap exists or what the `duration` parameter really does to slot boundaries. go through it and tell me what it does, where the surprises are, and which behaviours look intentional versus accidental", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "on-call docs claim the reminder job is idempotent and safe to re-run, and i want that verified rather than assumed before someone re-runs it during an incident at 3am. trace it properly: what it reads, what it writes, what happens if two copies run at once, and whether a patient could get two texts", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "schedule screen makes about forty network calls when you switch weeks quickly, one per day column, and half of them are cancelled mid-flight. the data layer is supposed to coalesce these. same behaviour on screen afterwards, but i want the fetching restructured so it's one request per week and cancellation is handled in one place", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "rails app has thirteen service objects under `app/services/appointments/` and four of them are wrappers around another one, which nobody can see without reading all thirteen. i'd like the layer flattened into something honest, same public entry points from the controllers, same behaviour, fewer indirections", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "every screen in the app builds its own retrofit call, its own loading boolean and its own error string, so the same three-state dance is written 20 times with subtle differences. i want one pattern applied everywhere without changing what any screen looks like or how it behaves offline", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "biggest source of paper cuts is that the confirmation modal, the sheet on mobile and the toast all render appointment times through different formatting helpers, so they disagree about am/pm and timezone suffixes. one helper, all three call sites, and the output should match the modal's current format", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "gradle config for the android app has accumulated flags from three years of stack overflow answers and nobody knows which are load-bearing. tidy it up, keep the build producing an identical APK, and tell me which flags you removed and why", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "before the multi-location work starts i want the current single-location assumptions written down — every place the code assumes one address, one timezone, one set of rooms — and then a phased plan for undoing them. the audit first, the plan second, both in one document if that reads better", "purpose": "planning", "secondary": "review", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "waitlist feature needs a design before code, but it also needs the offer expiry job soon or QA can't test anything. give me the design for the whole flow, then implement just the expiry worker against it so the rest can land behind it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "das Sync-Verhalten der App ist weder dokumentiert noch besonders durchdacht: Push vor Pull, Konflikte gewinnt immer der Server, verworfene Änderungen sieht der Nutzer nie. Ich hätte gern erst ein Konzept, wie es aussehen sollte, und danach die Umsetzung des Konfliktfalls im Repository", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "de"}
{"prompt": "nobody outside the team understands what the sync worker does, and the parts i understand look wrong. write the explainer for the rest of engineering, and while you're in there work out whether a discarded local edit can ever take a patient's cancellation with it", "purpose": "writing", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "support has asked for a page explaining why a reminder might not arrive, which needs to cover the timezone setting, the send window, the twilio number status and the do-not-disturb flag on the patient record. write that, and separately confirm from the code that those four are actually the only reasons", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "audit-trail schema we sketched last week never made it into the repo, and the ticket is now in this sprint. put the design into `docs/adr/` properly, then stand up the migration and the write path for API reads only — the admin panel can follow later", "purpose": "writing", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "`SyncCoordinator` and `AppointmentRepository` overlap so much that i can never remember which one owns the pending-edit queue. merge the responsibilities sensibly, and afterwards write the class-level docs so the boundary is obvious to whoever touches it next", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "there are two spawn systems in the unity project, the jam-era one and the new director, and both are wired into the boot scene. delete the dead one carefully, and note in the design doc which behaviours we deliberately dropped so the designers aren't surprised", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "scheduling API returns 200 with an empty array when a clinic's timezone is unset, which is how we shipped a 24-minute outage. work out every endpoint with that failure mode, then make them fail loudly instead", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "patient search is a plain LIKE query and takes two seconds on the bigger clinics. i want fuzzy matching on name and date of birth, with the exact matches ranked first", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "recurring provider blocks — lunch, admin time, theatre lists — need to exist as real records rather than one-off appointments, with an end date and the ability to skip a single occurrence", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "an internal endpoint that returns a clinic's next 30 days of capacity as a single payload, for the reporting screen. cache it for five minutes, key on clinic and provider filter", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "run summary screen at the end of a game — time survived, waves cleared, treatments used, a graph of damage over time, and a share button that copies a text summary", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "drag-to-reschedule on the web week grid, snapping to 15 minutes, with the original position ghosted while dragging", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "toast messages stack up and cover the FAB when sync retries, needs a proper snackbar host with a queue", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "boss health bar overlaps the wave banner at 21:9, and both are anchored to the top centre", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "what's the actual difference between `pull(null)` and `pull(lastSync)` in terms of what the server sends back", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "opinions on the `after_commit` calendar sync in the appointment model — is that going to bite us under load?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "is there anything in the waitlist offer flow that could offer the same slot to two patients at once", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "could someone explain the difference between our `Slot` and `Availability` models to me, they seem to overlap completely", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "someone needs to explain, in writing, what our appointment status transitions are — the code has six statuses and the docs mention four", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "give me a plain-english account of what the eligibility webhook handler does with a duplicate request id", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "how does the save system decide a run is finished — i can see two places that write the final state", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "docs/scheduling.md describes the availability algorithm from two rewrites ago, bring it in line with the code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "kdoc on our public data classes is copy-pasted from the field names and adds nothing, make it actually useful", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "`ClinicHours#slots_for` and `Availability#build` have grown into each other; separate the concerns without changing what the endpoint returns", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "pull the twilio and sendgrid calls behind one notification port so tests stop hitting HTTP stubs directly", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "enemy scripts each hold their own copy of the tuning numbers, move them to scriptable objects with the same values", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "rename the `booking` package to `appointments` across the android app, it's confused with the web team's `booking` for two years now", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "three components import `formatSlotTime` from three different files that all re-export the same function, collapse the chain", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "新しい医師を追加すると、既存の予約の色が全部変わってしまいます。色の割り当てを固定にできますか", "purpose": "quickFix", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.35, "slice": "mixed", "lang": "ja"}
{"prompt": "deep links from a reminder open the app but land on the schedule root instead of the appointment, and it's been like that since the navigation change", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we need a position on offline conflict resolution before the ios work starts, because copying android's silent server-wins would be a mistake to repeat twice", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "appointment reminders, waitlist offers and calendar sync all send messages, and each one built its own template handling. what would a single messaging layer look like here", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "whatever's next on the schedule board", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "mobile confirmation sheet shows only the time right now, which is useless when a patient has appointments at two of the clinic's sites. it needs the clinic name, the street address under it, a map button that opens the native maps app, and the provider's name — without making the sheet taller than the detent it opens at", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "setting up a dev environment here takes a full day because the instructions are spread across a wiki page, a pinned slack message and one engineer's memory. we need one document: prerequisites, the database seed step, how to point the app at the local API, how to get test twilio credentials, and the three things that always go wrong on a new mac", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "internally nobody can describe how appointment sync works without drawing on a whiteboard, so it gets explained badly and differently every time. one document, covering the pull path, the push path, what the revision numbers mean, when the worker gives up, and what the user sees at each stage — diagrams are welcome but the prose has to stand alone", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a patient who moved from Madrid to Mexico City still gets reminders on Spanish time as far as support can tell, and i want to know whether that's the code or the data. the reminder job reads the clinic timezone, not the patient's, so on paper it shouldn't matter — but the patient record has a timezone column that something must be using", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "sidekiq queue names drifted from the job class names over about two years, so `ReminderJob` runs on `default`, `CalendarSyncJob` runs on `mailers` of all things, and two jobs share a queue that's meant to be low priority. line them up with the class names, keep the priority weights we have today, and don't leave jobs stranded on the old queues during the deploy", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "providers keep asking for a view that's just their own day: their appointments only, defaulting to today, remembering the last provider they picked between launches, and usable one-handed while walking between rooms. it should open instantly from the local cache and refresh quietly behind that, with no spinner unless there's genuinely nothing cached", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "reporting is the screen clinics complain about most and also the one we understand least — five joins per row, no aggregates, and now they want twelve-month ranges. work out what it's really doing today and where the time goes, then propose whether we need a read model, a materialised view, or just better indexes. i want the analysis and the recommendation, not an implementation", "purpose": "planning", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "compose multiplatform versus two native codebases is the decision blocking our ios plan, and i'd rather see it reasoned through than argued about in standup. weigh it for our situation — four android engineers, one ios contractor, offline-first requirements, a design system that only exists for android — then draft the ADR whichever way it lands", "purpose": "planning", "secondary": "writing", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "bookings made close to midnight land on the wrong day for the provider but the right day for the patient, at least in Chile and probably anywhere with a negative offset. find out where the date gets derived from the wrong clock, and once you know, add the regression tests that would have caught it — parameterised over a few nasty timezones", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like someone to read the eligibility webhook handler with fresh eyes — signature check, replay handling, what happens when the patient reference is unknown — and tell me whether it matches the partner's spec. if the retry behaviour is as wrong as i suspect, fix the handler as part of the same pass", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "our appointment status transitions are documented as four states and implemented as six, and support has built workarounds around the undocumented ones. work out what the real state machine is from the code, then write the reference page that we should have had, flagging any transition that looks accidental", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "`app/services/appointments/` has thirteen classes where four would do, and half of them are one-line wrappers. consolidate the layer so the controllers call the same entry points they call today, then update the service-layer section of the architecture doc, which describes a structure we abandoned last year", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "the slot picker fails almost every accessibility check we run — no content descriptions on the chips, 32dp touch targets, and a focus order that jumps between columns. bring it up to standard, and take a screenshot pass afterwards so i can put the before and after in the procurement questionnaire", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt":"Incident timeline — INC-42142\n\n08:02 deploy BorealNimbusFormFlow 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 BorealNimbusFormFlow 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":"Release engineering needs a BorealFlintTimelineService 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":"Before we approve BorealGarnetModalStore, assess whether lost focus when the drawer animation finishes is an actual correctness risk or merely confusing structure. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"PM needs a concise migration note for BorealOpalRouterService, including the user impact, rollback trigger, and the one configuration key operators must change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealBirchMigratorCoordinator: handle the lingering thing","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Set BorealSlateEditorService's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Opal: # projects/boreal/services/ledger/replay.go\n[worker.borealravensessionflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealravensessionflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealravensessionflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealRavenSessionFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42143\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/boreal/services/ledger/replay.go and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Release verification found a single stale BorealIrisBatchService value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Kafka operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Dedupe BorealOrbitSyncService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Documente le contrat BorealRainfallDBStore","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"Why does BorealLumenChartService'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":"Give BorealCraneWorkspaceService a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Prism: // projects/boreal/Sources/App/SessionStore.swift\nfinal class BorealFrostPanelFlowCoordinator {\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 BorealFrostPanelFlow'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":"BorealSummitProxyService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Cloudflare Workers operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Quartz: // projects/boreal/crates/index/src/segment.rs\nfinal class BorealJuniperCLIFlowCoordinator {\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 BorealJuniperCLIFlow; 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":"BorealFlintTimelineCoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-42115: retire the legacy replay path for BorealBeaconStoreFlow\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 BorealBeaconStoreFlow 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":"BorealJuniperCLICoordinator needs a paired pass: produce a consumer guide for BorealJuniperCLICoordinator, plus correct the known stale timeout beside it. Use projects/boreal/pkg/cache/lease.rs as the source of truth, preserve the Cloudflare Workers contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Raven: Incident timeline — INC-42136\n\n08:02 deploy BorealOspreyJobFlow 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 BorealOspreyJobFlow 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":"BorealQuartzPlayerCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"BorealMicaProfileCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Sable: Release verification found a single stale BorealAmberFilterStore value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Kotlin coroutines operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'BorealEchoRegistryCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealEchoRegistryCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/web/components/FilterDrawer.vue:144: error: -[BorealEchoRegistryCoordinatorTests 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 '-[BorealEchoRegistryCoordinatorTests 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上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Use the UI evidence to complete BorealEchoRegistryCoordinator'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":"Introduce a durable deduplication key for BorealNimbusFormService 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":"Tide: projects/boreal/engine/render/atlas.cpp now contains BorealWillowCodecStore'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":"Umbra: Incident timeline — INC-42140\n\n08:02 deploy BorealGarnetModalFlow 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 BorealGarnetModalFlow 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.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Give BorealMoonlitSDKStore'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.5,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'BorealKiteSchedulerCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealKiteSchedulerCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/db/migrations/20260730_events.sql:144: error: -[BorealKiteSchedulerCoordinatorTests 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 '-[BorealKiteSchedulerCoordinatorTests 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\nReconstruct the BorealKiteSchedulerCoordinator 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":"Vela: The destination for BorealWrenExportStore is broadly agreed; the missing piece is a reversible route from projects/boreal/workers/thumbnail/consumer.ex to that target. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealWrenExportStore\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind BorealDriftConsoleStore's Cloudflare Workers 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":"Walk through BorealFernSnapshotStore's atlas.cpp","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Compare the old and new BorealSpruceDaemonStore adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind BorealCinderAuthStore's GraphQL 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":"Ticket OPS-42157: retire the legacy replay path for BorealVelaDrawerCoordinator\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 BorealVelaDrawerCoordinator 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":"diff --git a/projects/boreal/ml/pipeline/features.py b/projects/boreal/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/ml/pipeline/features.py\n+++ b/projects/boreal/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 BorealNovaPickerFlow'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.7,"slice":"pasted-context","lang":"en"}
{"prompt":"A previously stable test around BorealBirchMigratorService 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":"Dokumentiere BorealQuartzPlayerStore kurz","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"de"}
{"prompt":"For BorealHarborIndexCoordinator, separate BorealHarborIndexCoordinator's policy from transport without behavior changes; once that is complete, capture the contract and rollback note for consumers. Work from projects/boreal/internal/auth/refresh.go, stay with Kotlin coroutines, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Is BorealBeaconStoreService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"On compact widths, BorealBasilRunnerFlow'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":"Two asks around BorealCedarPolicyCoordinator: (1) find the unknown cause of two validators with subtly different error strings; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"BorealSableParserService has four wrappers that only translate the same error enum. Collapse them into one adapter and preserve every public case, message, and metric label.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"projects/boreal/lib/codec/frame.cc has grown through several launches, and BorealIrisBatchStore now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to BorealIrisBatchStore and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL 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":"BorealSpruceDaemonCoordinator: could this be clearer","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealSableParserCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","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_42122'\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_42122'::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\nDetermine why BorealFernSnapshotFlow 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":"BorealNimbusFormCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealAcornWidgetCoordinator: correct, then assess","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"BorealSlateEditorCoordinator: sequence, then polish","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealPrismCacheService'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":"Move BorealSummitProxyFlow'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.5,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/boreal/db/migrations/20260730_events.sql, 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.8,"slice":"core","lang":"en"}
{"prompt":"The BorealDeltaCanvasStore empty state in projects/boreal/config/staging.toml 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.4,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current BorealEmberRelayService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealEmberRelayService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"On compact widths, BorealCinderAuthService'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":"BorealRainfallDBCoordinator needs a paired pass: separate BorealRainfallDBCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/boreal/ui/settings/PrivacyPane.tsx as the source of truth, preserve the Kafka contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current BorealDriftConsoleService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealDriftConsoleService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: BorealMarbleTokenService has one known configuration mistake in projects/boreal/infra/modules/edge/main.tf, not an open-ended failure investigation. 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- leave generated files and vendored code alone\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to BorealMarbleTokenService and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-42128\n\n08:02 deploy BorealHarborIndexFlow 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 BorealHarborIndexFlow 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":"diff --git a/projects/boreal/cmd/exporter/main.py b/projects/boreal/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/cmd/exporter/main.py\n+++ b/projects/boreal/cmd/exporter/main.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\nRestructure BorealPineMetricsFlow 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":"In projects/boreal/app/src/main/SyncWorker.kt hat BorealAtlasSearchService ein sporadisches Problem im GraphQL-Ablauf. Vervollständige Responsive Layout, Empty- und Retry-State, Tastaturfokus, Dark Mode und Reduced Motion.\n\nRandbedingungen:\n- GraphQL weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf BorealAtlasSearchService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um BorealAtlasSearchService mit GraphQL kompatibel.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"Split BorealAsterWebhookStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The name pendingAck means two different things across BorealMarbleTokenFlow'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":"# projects/boreal/packages/api/openapi.yaml\n[worker.borealquartzplayerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealquartzplayerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealquartzplayerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealQuartzPlayerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42119\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/boreal/packages/api/openapi.yaml and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Dedupe BorealFrostPanelStore's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Stream BorealFernSnapshotService's audit events","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Does BorealOspreyJobStore enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"PM needs a concise migration note for BorealFlintTimelineStore, including the user impact, rollback trigger, and the one configuration key operators must change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealOrbitSyncCoordinator is blocking the next release because cancellation being swallowed at the repository boundary. I need two concrete outcomes from a single pass: assess ownership and failure handling in projects/boreal/crates/index/src/segment.rs, and capture the contract and rollback note for consumers. Use the existing Cloudflare Workers conventions in projects/boreal/crates/index/src/segment.rs; leave generated files and vendored code alone. 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":"Ticket OPS-42114: retire the legacy replay path for BorealOrbitSyncFlow\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 BorealOrbitSyncFlow 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":"BorealOspreyJobCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new BorealVelaDrawerStore 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":"Remove BorealFrostPanelService's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"BorealGarnetModalCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Willow: The BorealMicaProfileStore surface in projects/boreal/ml/pipeline/features.py 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":"Xylem: projects/boreal/web/components/FilterDrawer.vue 里的 BorealRavenSessionStore 最近在 Kotlin coroutines 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 Kotlin coroutines\n- 保持兼容性和取消语义\n- 改动只限于 BorealRavenSessionStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Two deliverables are holding up BorealBeaconStoreCoordinator. First, finish BorealBeaconStoreCoordinator's responsive empty and retry states. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/boreal/cmd/exporter/main.py, which follows Spring Boot conventions and currently suffers from a feature flag whose default differs between environments. Leave generated files and vendored code alone.\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":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Yarrow: Two asks around BorealCraneWorkspaceCoordinator: (1) change BorealCraneWorkspaceCoordinator's known staging timeout from 15 to 30 seconds; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, 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":"Zephyr: Ticket OPS-42151: retire the legacy replay path for BorealEmberRelayCoordinator\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 BorealEmberRelayCoordinator 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":"Where did BorealHarborIndexService's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/boreal/infra/modules/edge/main.tf:217:18:\ncalled `Result::unwrap()` on an `Err` value: SendError { .. }\n\nstack backtrace:\n 0: std::panicking::begin_panic_handler\n 1: core::panicking::panic_fmt\n 2: core::result::unwrap_failed\n 3: borealbirchmigratorflow::scheduler::LeaseTask::flush\n at ./projects/boreal/infra/modules/edge/main.tf:217:18\n 4: borealbirchmigratorflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nFind the source of this BorealBirchMigratorFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Test Suite 'BorealSpruceDaemonFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealSpruceDaemonFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/config/staging.toml:144: error: -[BorealSpruceDaemonFlowTests 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 '-[BorealSpruceDaemonFlowTests 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\nDetermine why BorealSpruceDaemonFlow 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":"Before touching projects/boreal/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.8,"slice":"core","lang":"en"}
{"prompt":"# CI job 42147: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Kafka\n\n[setup] restoring cache key deps-a2f91c ... hit\n[setup] starting postgres:17 ... healthy after 4.2s\n[setup] starting redis:8 ... healthy after 0.8s\n[test] shard 3/8 selected 412 tests\n[test] BorealLumenChartFlowIntegration.replays_after_timeout ... ok\n[test] BorealLumenChartFlowIntegration.cancels_orphaned_batch ... FAILED\n\nExpected:\n pending_jobs{queue=\"replay\"} 0\nActual:\n pending_jobs{queue=\"replay\"} 1\n\nCaptured spans:\n batch.receive 2.1ms status=ok\n storage.transaction 44.8ms status=cancelled\n batch.nack <missing>\n\nteardown warning: resource still in use: redis connection pool (1 borrower)\nretry 1/2 with identical seed ... passed\nretry 2/2 with identical seed ... passed\n\nThe failure began after the test suite was sharded, but it sometimes appears on an unsharded nightly run. There are no wall-clock sleeps in this test; it advances the fake scheduler until idle.\n\nWire BorealLumenChartFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Checkout: projects/boreal/src/sync/reconcile.ts now contains BorealKiteSchedulerFlow'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":"Test Suite 'BorealWrenExportFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealWrenExportFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/ui/settings/PrivacyPane.tsx:144: error: -[BorealWrenExportFlowTests 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 '-[BorealWrenExportFlowTests 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 BorealWrenExportFlow'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":"Exporter: # projects/boreal/ui/settings/PrivacyPane.tsx\n[worker.borealprismcacheflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealprismcacheflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealprismcacheflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealPrismCacheFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42137\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\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/boreal/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":"Scheduler: // projects/boreal/Sources/CLI/Commands/Doctor.swift\nfinal class BorealAsterWebhookFlowCoordinator {\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 BorealAsterWebhookFlow 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.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-42112\n\n08:02 deploy BorealIrisBatchFlow 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 BorealIrisBatchFlow 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":"Ticket OPS-42129: retire the legacy replay path for BorealCopperBridgeFlow\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\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Turn the artifact into a reversible BorealCopperBridgeFlow 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":"Outline a safer BorealCraneWorkspaceStore cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-42110: finish the compact BorealMosaicGridFlow filter experience\n\nRoute: /catalog/search\nSource: projects/boreal/Sources/CLI/Commands/Doctor.swift\nFramework: Spring Boot\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 BorealMosaicGridFlow 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":"diff --git a/projects/boreal/web/components/FilterDrawer.vue b/projects/boreal/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/web/components/FilterDrawer.vue\n+++ b/projects/boreal/web/components/FilterDrawer.vue\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 BorealTideWorkerFlow 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":"BorealCinderAuthCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"How should BorealLedgerGateStore be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Em projects/boreal/cmd/exporter/main.py, o BorealNovaPickerStore tem um problema intermitente no fluxo de Spring Boot. Proponha fases, compatibilidade, métricas, rollback e ownership; pare antes de alterar código.\n\nRestrições:\n- continuar com Spring Boot\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao BorealNovaPickerStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"pt"}
{"prompt":"Dashboard: Incident timeline — INC-42146\n\n08:02 deploy BorealCinderAuthFlow 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 BorealCinderAuthFlow 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":"A previously stable test around BorealOpalRouterStore 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":"Worker: The BorealWillowCodecFlow 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":"PM is preparing the BorealMosaicGridService rollout and needs prose that works for both application developers and the operators who will carry the pager. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealMosaicGridService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"BorealMapleQueueStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/boreal/ml/pipeline/features.py and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"BorealAsterWebhookCoordinator needs a paired pass: change BorealAsterWebhookCoordinator's known staging timeout from 15 to 30 seconds, plus give the existing implementation a read-only safety pass. Use projects/boreal/Sources/App/SessionStore.swift as the source of truth, preserve the Spring Boot contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"BorealCopperBridgeService flakes under UTC","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"projects/boreal/services/ledger/replay.go の BorealRavenSessionService で、Kotlin coroutines の flow に断続的な問題が起きています。 responsive layout、empty/retry state、keyboard focus、dark mode、reduced motion を仕上げてください。\n\n制約:\n- Kotlin coroutines を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は BorealRavenSessionService のみ","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"ja"}
{"prompt":"Please resist widening this one: BorealMarbleTokenStore works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealMarbleTokenStore\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Simulator: // projects/boreal/workers/thumbnail/consumer.ex\nfinal class BorealRainfallDBFlowCoordinator {\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 BorealRainfallDBFlow; 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":"UI ticket DES-42134: finish the compact BorealOpalRouterFlow filter experience\n\nRoute: /catalog/search\nSource: projects/boreal/pkg/cache/lease.rs\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 BorealOpalRouterFlow 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":"Walk through BorealJuniperCLIService's segment.rs","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealPrismCacheCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealDeltaCanvasCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Summarize the BorealWrenExportService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealMoonlitSDKCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/boreal/packages/api/openapi.yaml b/projects/boreal/packages/api/openapi.yaml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/packages/api/openapi.yaml\n+++ b/projects/boreal/packages/api/openapi.yaml\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 BorealDeltaCanvasFlow 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":"Match BorealPineMetricsService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Incident timeline — INC-42158\n\n08:02 deploy BorealMarbleTokenCoordinator 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 BorealMarbleTokenCoordinator 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":"Release engineering needs a BorealDriftConsoleFlow 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":"Why is BorealLedgerGateService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"What sequence would let BorealDeltaCanvasService adopt Cloudflare Workers 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":"Enforce BorealTideWorkerStore's idempotency key","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Ownership of BorealCoralUploadStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current GraphQL operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Documente o contrato de BorealRainfallDBService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current BorealAmberFilterService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealAmberFilterService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Extract BorealCedarPolicyService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Does BorealPineMetricsStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"projects/boreal/cmd/exporter/main.py has grown through several launches, and BorealBeaconStoreStore now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to BorealBeaconStoreStore and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL 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":"Ticket OPS-42155: retire the legacy replay path for BorealMapleQueueCoordinator\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\nUsing this as the starting evidence, propose a staged BorealMapleQueueCoordinator 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":"Runbook: diff --git a/projects/boreal/web/components/FilterDrawer.vue b/projects/boreal/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/web/components/FilterDrawer.vue\n+++ b/projects/boreal/web/components/FilterDrawer.vue\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Restructure BorealAmberFilterFlow 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":"BorealSableParserStore's staging timeout is already known to be wrong: change the single projects/boreal/infra/modules/edge/main.tf value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale BorealKiteSchedulerService value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current GraphQL operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Trace: Ticket OPS-42150: retire the legacy replay path for BorealBasilRunnerCoordinator\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 BorealBasilRunnerCoordinator 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.7,"slice":"pasted-context","lang":"en"}
{"prompt":"What does BorealJuniperCLIStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Outline a safer BorealAcornWidgetService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Profiler: Incident timeline — INC-42144\n\n08:02 deploy BorealFlintTimelineFlow 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 BorealFlintTimelineFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Console: # projects/boreal/internal/auth/refresh.go\n[worker.borealacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42118\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/boreal/internal/auth/refresh.go. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Workspace: projects/boreal/apps/console/routes/usage.svelte の BorealEmberRelayFlow で、GraphQL の flow に断続的な問題が起きています。 consumer 向けに contract、error、retry、コピー可能な例を含む文書を書き、handler は変更しないでください。\n\n制約:\n- GraphQL を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は BorealEmberRelayFlow のみ","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"ja"}
{"prompt":"Fresh release brief for BorealMosaicGridCoordinator:\n- primary outcome: finish BorealMosaicGridCoordinator's responsive empty and retry states\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/boreal/Sources/App/SessionStore.swift\n- platform constraint: Spring Boot\n- known complication: two validators with subtly different error strings\n\nBoth results are required, but they should remain independently reviewable. Leave generated files and vendored code alone; 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":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"PM is preparing the BorealVelaDrawerService rollout and needs prose that works for both application developers and the operators who will carry the pager. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealVelaDrawerService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Repository: Release verification found a single stale BorealMosaicGridStore value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Spring Boot operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Read projects/boreal/Sources/App/SessionStore.swift and tell me whether BorealGarnetModalService 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":"Assess the BorealAcornWidgetStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealLumenChartStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/boreal/ui/settings/PrivacyPane.tsx and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Give BorealEchoRegistryFlow'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":"Split projects/boreal/app/src/main/SyncWorker.kt by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Ownership of BorealBasilRunnerService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Spring Boot operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"BorealFrostPanelCoordinator: sequence, then restructure","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-42154\n\n08:02 deploy BorealDriftConsoleCoordinator 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 BorealDriftConsoleCoordinator 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":"Documente le contrat BorealQuartzPlayerService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"How does BorealEchoRegistryStore propagate cancellation through the Kotlin coroutines boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter BorealAtlasSearchFlow\n RUN v3.2.4 /workspace/apps/console\n × BorealAtlasSearchFlow > restores a suspended upload after reconnect 1543ms\n → expected cursor \"seg-0184\" to equal \"seg-0183\"\n\nAssertionError: expected 'seg-0184' to deeply equal 'seg-0183'\n at packages/sync/test/reconnect.spec.ts:188:31\n at async withFakeClock (packages/testkit/clock.ts:72:9)\n at async Promise.all (index 1)\n\nstdout:\n session=42111 phase=resume storedCursor=seg-0183\n session=42111 phase=fetch requestCursor=seg-0183 pageSize=200\n session=42111 phase=commit receivedCursor=seg-0184 itemCount=0\n session=42111 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the BorealAtlasSearchFlow 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":"Pipeline: What is the safest way to split projects/boreal/apps/console/routes/usage.svelte into independently owned modules while BorealMoonlitSDKService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"Add a bounded BorealBasilRunnerStore export stream that resumes from checkpoints, respects cancellation, and exposes queue lag plus terminal failure counters.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up BorealIrisBatchCoordinator. First, separate BorealIrisBatchCoordinator'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/boreal/lib/codec/frame.cc, which follows Kafka conventions and currently suffers from a misleading timeout name used in five packages. Leave generated files and vendored code alone.\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.9,"slice":"mixed","lang":"en"}
{"prompt":"For BorealPineMetricsCoordinator, finish BorealPineMetricsCoordinator's responsive empty and retry states; once that is complete, give the existing implementation a read-only safety pass. Work from projects/boreal/ml/pipeline/features.py, stay with Spring Boot, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"En projects/boreal/apps/console/routes/usage.svelte, BorealAtlasSearchStore tiene un problema intermitente en el flujo de GraphQL. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con GraphQL\n- conservar compatibilidad y cancelación\n- limitar el cambio a BorealAtlasSearchStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con GraphQL alrededor de BorealAtlasSearchStore.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"BorealLumenChartCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Two asks around BorealCopperBridgeCoordinator: (1) ship the idempotent BorealCopperBridgeCoordinator replay endpoint; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Clarify BorealSlateEditorStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-42116: finish the compact BorealCoralUploadFlow filter experience\n\nRoute: /catalog/search\nSource: projects/boreal/db/migrations/20260730_events.sql\nFramework: GraphQL\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 BorealCoralUploadFlow 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":"core","lang":"en"}
{"prompt":"BorealTideWorkerCoordinator needs a paired pass: assess ownership and failure handling in projects/boreal/services/ledger/replay.go, plus capture the contract and rollback note for consumers. Use projects/boreal/services/ledger/replay.go as the source of truth, preserve the Kotlin coroutines contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Clarify BorealCloudReconcilerService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/boreal/apps/console/routes/usage.svelte:217:18:\ncalled `Result::unwrap()` on an `Err` value: SendError { .. }\n\nstack backtrace:\n 0: std::panicking::begin_panic_handler\n 1: core::panicking::panic_fmt\n 2: core::result::unwrap_failed\n 3: borealmoonlitsdkflow::scheduler::LeaseTask::flush\n at ./projects/boreal/apps/console/routes/usage.svelte:217:18\n 4: borealmoonlitsdkflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nReconstruct the BorealMoonlitSDKFlow 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.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-42159: retire the legacy replay path for BorealSummitProxyCoordinator\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 BorealSummitProxyCoordinator 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":"BorealOpalRouterCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealSpruceDaemonService'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":"Fresh release brief for BorealAmberFilterCoordinator:\n- primary outcome: separate BorealAmberFilterCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/boreal/services/ledger/replay.go\n- platform constraint: Kotlin coroutines\n- known complication: stale cursors when a page is resumed\n\nBoth results are required, but they should remain independently reviewable. Leave generated files and vendored code alone; 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":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Compare BorealHarborIndexStore's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The BorealOspreyJobService 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":"BorealNovaPickerCoordinator: polish the last piece","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"For BorealCloudReconcilerCoordinator, finish BorealCloudReconcilerCoordinator's responsive empty and retry states; once that is complete, give the existing implementation a read-only safety pass. Work from projects/boreal/apps/console/routes/usage.svelte, stay with GraphQL, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"The first BorealPrismCacheStore 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":"BorealWrenExportCoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/boreal/apps/console/routes/usage.svelte b/projects/boreal/apps/console/routes/usage.svelte\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/apps/console/routes/usage.svelte\n+++ b/projects/boreal/apps/console/routes/usage.svelte\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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Split BorealSlateEditorFlow 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":"Gateway: Ticket OPS-42131: retire the legacy replay path for BorealCloudReconcilerFlow\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 material above into a concise BorealCloudReconcilerFlow 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":"BorealLedgerGateCoordinator: restructure, then correct","purpose":"refactor","secondary":"backendImpl","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"projects/boreal/ml/pipeline/features.py 里的 BorealNovaPickerService 最近在 Spring Boot 流程中出现间歇性问题。 请写一份面向调用方的说明，包含 contract、错误、retry 和可复制示例，不要改 handler。\n\n约束：\n- 继续使用 Spring Boot\n- 保持兼容性和取消语义\n- 改动只限于 BorealNovaPickerService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"zh"}
{"prompt":"Rename BorealTideWorkerService's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-42145: retire the legacy replay path for BorealMicaProfileFlow\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\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Map a safe route from the current BorealMicaProfileFlow 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":"En projects/boreal/services/ledger/replay.go, BorealEchoRegistryService 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 BorealEchoRegistryService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"es"}
{"prompt":"BorealCoralUploadCoordinator: polish, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Persist BorealCoralUploadService's replay cursor","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter BorealCraneWorkspaceFlow\n RUN v3.2.4 /workspace/apps/console\n × BorealCraneWorkspaceFlow > restores a suspended upload after reconnect 1543ms\n → expected cursor \"seg-0184\" to equal \"seg-0183\"\n\nAssertionError: expected 'seg-0184' to deeply equal 'seg-0183'\n at packages/sync/test/reconnect.spec.ts:188:31\n at async withFakeClock (packages/testkit/clock.ts:72:9)\n at async Promise.all (index 1)\n\nstdout:\n session=42132 phase=resume storedCursor=seg-0183\n session=42132 phase=fetch requestCursor=seg-0183 pageSize=200\n session=42132 phase=commit receivedCursor=seg-0184 itemCount=0\n session=42132 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the BorealCraneWorkspaceFlow 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.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-42138\n\n08:02 deploy BorealSableParserFlow 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 BorealSableParserFlow, 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":"A copied hex color in BorealMicaProfileService 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":"Please resist widening this one: BorealOrbitSyncStore works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealOrbitSyncStore\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealAtlasSearchCoordinator is blocking the next release because memory growth during hour-long imports. I need two concrete outcomes from a single pass: change BorealAtlasSearchCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing GraphQL conventions in projects/boreal/apps/console/routes/usage.svelte; leave generated files and vendored code alone. 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.7,"slice":"mixed","lang":"en"}
{"prompt":"Summarize the BorealCloudReconcilerStore changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Does BorealBirchMigratorStore enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"We expect BorealMapleQueueService to outgrow its current Spring Boot arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to BorealMapleQueueService and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","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_42126'\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_42126'::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\nWire BorealCedarPolicyFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealFernSnapshotCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/boreal/engine/render/atlas.cpp b/projects/boreal/engine/render/atlas.cpp\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/engine/render/atlas.cpp\n+++ b/projects/boreal/engine/render/atlas.cpp\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 BorealWillowCodecCoordinator'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":"A copied hex color in BorealMapleQueueFlow 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":"Where did BorealCedarPolicyStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"Is there a cleaner way to separate BorealVelaDrawerFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Dedupe BorealAsterWebhookService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"We expect BorealSummitProxyStore to outgrow its current Cloudflare Workers arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to BorealSummitProxyStore and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Is BorealCopperBridgeStore safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: BorealWillowCodecService has one known configuration mistake in projects/boreal/lib/codec/frame.cc, not an open-ended failure investigation. 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- leave generated files and vendored code alone\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to BorealWillowCodecService and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealRavenSessionCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'BorealLedgerGateFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/services/ledger/replay.go:144: error: -[BorealLedgerGateFlowTests 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 '-[BorealLedgerGateFlowTests 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 BorealLedgerGateFlow'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"}