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-13.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "hub firmware updates brick about one device in two hundred:\n\nOTA log from a failed device (recovered over serial):\n [ota] downloading 4.2.1, 8,412,004 bytes\n [ota] verifying signature... ok\n [ota] writing slot B, 8,412,004 bytes\n [ota] write complete, crc ok\n [ota] setting boot flag to B\n [ota] rebooting\n [boot] slot B invalid magic, falling back to slot A\n [boot] slot A invalid magic\n [boot] no valid image, entering recovery\n\nthe boot flag write and the slot B write are on the same flash sector, and the erase before writing the flag wipes the last 4KB of the image", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "our prompt and schema for clause extraction, which i'd like a second opinion on:\n\nSCHEMA = {\n \"type\": \"object\",\n \"required\": [\"clauses\", \"governing_law\", \"termination_notice_days\"],\n \"properties\": {\n \"clauses\": {\"type\": \"array\", \"items\": {\"type\": \"object\", \"required\": [\"type\", \"text\", \"page\"]}},\n \"governing_law\": {\"type\": \"string\"},\n \"termination_notice_days\": {\"type\": \"integer\"}\n }\n}\n\nEXTRACT_PROMPT = \"Extract all clauses from the following contract. Return JSON matching the schema.\\n\\n{text}\"\n\ntermination_notice_days became required on monday; plenty of contracts don't state one; and the validator's repair loop is what runs when the model omits it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "the hub's state handling is spread across three tasks with shared atomics:\n\nstatic LINK_DOWN: AtomicBool\nstatic MQTT_CONNECTED: AtomicBool\nstatic LAST_PUBLISH_OK: AtomicU64\nstatic OTA_IN_PROGRESS: AtomicBool\n\n// net task sets LINK_DOWN\n// mqtt task reads LINK_DOWN, sets MQTT_CONNECTED and LAST_PUBLISH_OK\n// ota task reads MQTT_CONNECTED, sets OTA_IN_PROGRESS\n// the watchdog reads all four and decides whether to reboot\n\nfour booleans encoding a state machine nobody has written down, and the watchdog's reboot decision is the most safety-relevant code we have\n\nfor reference, the watchdog:\n\nfn watchdog(state: &State) {\n let link = LINK_DOWN.load(Ordering::Relaxed);\n let mqtt = MQTT_CONNECTED.load(Ordering::Relaxed);\n let last = LAST_PUBLISH_OK.load(Ordering::Relaxed);\n let ota = OTA_IN_PROGRESS.load(Ordering::Relaxed);\n if !ota && !link && !mqtt && now_secs() - last > 900 {\n log::error!(\"watchdog: rebooting, no successful publish for 15 minutes\");\n reboot();\n }\n}\n\nnote that a hub deadlocked in publish has MQTT_CONNECTED true and LINK_DOWN false, so the watchdog never fires — which is exactly the field failure we're seeing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "device events through one handler table", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "matchmaking queues stall for one region at peak and i can't see why from the metrics:\n\nmatchmaker_queue_depth{region=\"eu-west\"} 41,882\nmatchmaker_matches_created{region=\"eu-west\"} 0/s (normally 120/s)\nmatchmaker_ticket_age_p99{region=\"eu-west\"} 412s\nmatchmaker_pool_scan_duration{region=\"eu-west\"} 8.4s (normally 40ms)\nmatchmaker_backfill_active{region=\"eu-west\"} 1,204\n\nother regions are healthy with the same build. the scan is O(n²) over the pool and eu-west is our biggest region, but this only started last week", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "our device integration API, which three hardware partners build against from a PDF we wrote in 2024:\n\nMQTT topics:\n hub/{hub_id}/state hub → cloud, retained, QoS 1, at most every 30s\n hub/{hub_id}/event hub → cloud, not retained, QoS 1\n hub/{hub_id}/cmd cloud → hub, QoS 1, hub must ack on .../cmd/ack within 5s\n hub/{hub_id}/ota cloud → hub, QoS 1, payload is a signed manifest\n\nthings partners get wrong: state is retained so a stale state survives a hub being offline for days; commands are not idempotent and a redelivery after a missed ack will run twice; the ack topic is per-command not per-hub; and QoS 1 means duplicates are expected rather than exceptional\n\nwrite the integration reference for partners", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "the extraction team's list, with finance watching the model bill:\n\n- stop sending the full document in repair prompts; send the failing section\n- make termination_notice_days optional, or teach the model to return null with a reason\n- measure cost per customer per stage, which we currently cannot do at all\n- version prompts and record which version produced which result\n- add a circuit breaker so a rate limit doesn't back up the whole queue\n- evaluate whether the layout model is still needed now that OCR quality improved\n\ntwo engineers, and the bill is the thing leadership is looking at", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "device state lives in the hub's memory, a retained MQTT message and postgres, and all three disagree often enough that support checks all three by habit. work through what a single authoritative store would mean for offline reconciliation, for the automation engine's read latency, and for the three hardware partners who read retained messages today", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "hub firmware encodes its state machine as four static atomics read by four tasks, including the watchdog that decides whether to reboot a device in someone's home. before we touch any of it i'd like agreement on what the states actually are and how they're represented, because the current arrangement is why the deadlock is so hard to reason about", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "what counts as a counter reset?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "extraction quality halved overnight for one customer with no code change, and the only thing that changed on their side was a new scanner. work through the pipeline stage by stage — OCR confidence, layout, chunk sizes — and tell me where the quality is actually lost rather than where it first becomes visible i'd like enough detail that i can hand it to someone else to finish.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "matchmaking again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "clause extraction quality collapsed for one customer overnight, same model, same prompts:\n\nrun 8f2b1c (yesterday): 412 documents, mean clauses extracted 41.2, human agreement 0.91\nrun 91cc40 (today): 409 documents, mean clauses extracted 12.8, human agreement 0.44\n\npipeline stages:\n pdf → ocr (tesseract 5.3) → layout (our model) → chunker → extractor (LLM) → validator\n\nocr confidence mean: 0.94 → 0.62\nchunker: mean chunk length 1,800 chars → 410 chars\nextractor: prompt unchanged, temperature 0, same model version\n\nthe customer started uploading scans from a new office scanner on monday", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "three places compute a device's \"is online\" state and they disagree:\n\n// api/devices.rs\nfn online(d: &Device) -> bool { d.last_seen_at > Utc::now() - Duration::minutes(5) }\n\n// automation/engine.rs\nfn online(d: &Device) -> bool { d.mqtt_session_present && d.last_state_at.is_some() }\n\n// mobile app (kotlin)\nfun isOnline(d: Device) = d.lastSeenAt.isAfter(Instant.now().minusSeconds(120))\n\nthe automation engine's version is the one that decides whether a rule runs, the app's is what the user sees, and support has learned to check all three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "queue timer is announced every second", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "is the boot flag on its own sector?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "a legal customer's security team asked six specific questions about document handling and our honest answers are mostly uncomfortable. answer each from the code and the contracts, write it as a publishable page, and mark clearly where the answer is \"not today\" rather than dressing it up flag anything you'd want to change before doing it rather than after.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "extraction pipeline module does orchestration, retries, cost accounting and prompt assembly in seven hundred lines. split it, then document which piece owns retries because that's the question every incident starts with", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "what does the automation engine do when a device is offline at evaluation time", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "hubs stop reporting after a few days in the field and only ever recover with a power cycle:\n\n[2026-07-29T02:14:02Z WARN lumen_hub::mqtt] publish timed out after 30s, topic=hub/8f2b/state\n[2026-07-29T02:14:32Z WARN lumen_hub::mqtt] publish timed out after 30s, topic=hub/8f2b/state\n[2026-07-29T02:15:02Z ERROR lumen_hub::mqtt] outgoing queue full (1024), dropping message\n[2026-07-29T02:15:02Z INFO lumen_hub::net] link down (wlan0)\n[2026-07-29T02:15:04Z INFO lumen_hub::net] link up (wlan0), ip 192.168.1.44\n[2026-07-29T02:15:04Z INFO lumen_hub::mqtt] reconnect scheduled in 1s\n[2026-07-29T02:15:05Z INFO lumen_hub::mqtt] connecting to mqtts://ingest.lumen.io:8883\n<no further mqtt log lines, hub keeps running>\n\nthe reconnect task takes the client mutex and the publish path is still holding it waiting on the old socket", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "document uploads fail for exactly one customer and only for large files:\n\nPOST /v1/documents (multipart, 84MB pdf)\n → 413 Request Entity Too Large after 41s\n\nnginx: client_max_body_size 100m\ningress: proxy-body-size: 100m\napp: MAX_UPLOAD_BYTES = 104857600\ncdn: max request body 50MB (not configurable on our plan)\n\nthis customer's uploads go through the CDN because they're on our EU endpoint; everyone else hits the origin directly\n\ntimings from the failing request, captured at the CDN:\n request started 11:02:14.101\n bytes received 52,428,800 of 88,080,384\n connection closed by edge 11:02:55.882\n status returned to client 413\n\nand from our origin: no request logged at all, so nothing reached nginx\n\nthe customer is on the EU endpoint because of a data residency clause added to their contract in march; everyone else resolves straight to the origin load balancer", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "players report being matched with wildly different skill levels, here's a sample match:\n\nmatch m_88412, mode=ranked_5v5, region=na-east, created 11:02:14\n team A skill: 1204, 1188, 1211, 1197, 1206 (mean 1201)\n team B skill: 1198, 1210, 1189, 2410, 1205 (mean 1442)\n ticket ages at match time: 8s, 11s, 9s, 412s, 10s\n\nour relaxation schedule widens the skill window by 100 every 30 seconds with no cap, and the 412-second ticket had a window of ±1400 by the time it matched", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "could you look at the reconnect logic before i sign off on it? the mutex worries me:\n\npub async fn publish(&self, topic: &str, payload: &[u8]) -> Result<()> {\n let mut client = self.client.lock().await;\n client.publish(topic, QoS::AtLeastOnce, false, payload).await\n}\n\nasync fn reconnect_task(state: Arc<State>) {\n loop {\n if state.link_down.load(Ordering::Relaxed) {\n let mut client = state.client.lock().await;\n *client = MqttClient::connect(&state.opts).await?;\n state.link_down.store(false, Ordering::Relaxed);\n }\n sleep(Duration::from_secs(1)).await;\n }\n}\n\npublish has a 30 second timeout on the network call but no timeout on acquiring the lock", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the hub firmware 4.2.2, which is the recovery release:\n\n41c9e0b fix(ota): boot flag moved to its own flash sector\n88f21c0 fix(ota): image tail verified after the flag write, not before\nc0aa774 fix(mqtt): publish no longer holds the client lock across a network timeout\n2e91b45 feat(energy): counter resets are detected and reported explicitly\naa30f19 fix(net): reconnect backoff is now exponential with jitter, capped at 5 minutes\n9c1d004 chore: bootloader minimum version is now 2.1\n4410bb7 feat(recovery): a hub with no valid image now exposes a recovery access point\nb77e910 fix(time): hub clock is validated against the server before signing telemetry\n\nour readers are partner hardware teams and our own support staff; two of these are the fix for bricked devices and one requires a bootloader update first", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the home app's automation editor, which is where users spend their time:\n\nAutomation editor (mobile, portrait)\n- Trigger, conditions and actions as three stacked sections, each a list with an add row at the bottom.\n- Adding a trigger opens a sheet of device categories, then devices, then the trigger for that device — three taps maximum to a common case.\n- A condition that can never be true (a sensor that doesn't report the attribute) is flagged inline at edit time, not on save.\n- Actions show the device's current state next to them, greyed if the device is offline, with the last-seen time on tap.\n- Saving an automation that references an offline device warns but does not block, because devices come back.\n- A test run button executes the actions immediately and shows per-action success or failure, which is the single most requested feature.\n- Everything must be operable one-handed and legible in a dark room at minimum brightness.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "review panes desync on zoom", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "one online check for devices", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "prompts out of the pipeline module", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "why did extraction quality drop overnight?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "energy totals jump backwards", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "eu-west queues stall at peak", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "automation screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "next thing on the board", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "model bill tripled because a schema change made a rarely-produced field required and the repair loop resends the whole document five times. beyond the immediate fix i want a position on how we control model cost structurally — per-stage budgets, circuit breakers, cost attribution per customer — because this will happen again with a different field", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "we owe thirty-eight households an explanation for why their heating controller stopped working overnight and needs replacing. write the customer notification — plain language, no blame-shifting to the update process, clear about the replacement and the timeline — and a separate internal write-up for the hardware team that doesn't spare us", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "internal documentation on model calls doesn't exist, and every engineer rediscovers the retry behaviour, the cost accounting gaps and the fact that a rate limit backs up the whole queue. write the guide for internal developers covering how a call is made, what happens on failure, and what it costs this has come up in three separate reviews now and never gets done.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "nobody can tell me whether the publish path can deadlock against the reconnect task, or whether the symptom is something else entirely — hubs go quiet and only a power cycle helps. read both paths and the lock discipline around the client and tell me exactly what sequence produces a hub that keeps running but never publishes again there's no rush on this week specifically, but it keeps costing us time.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "partner cloud-to-cloud integration lands in october and their protocol has no sequence numbers and no completion callbacks. design how we reconcile out-of-order state and asynchronous commands, then build the webhook receiver against it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "hub's four state atomics should become one state machine. do the conversion, and tell me whether the watchdog's reboot decision changes for any state it currently sees", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like an honest read of whether a device's energy counter reset can be distinguished from a genuine drop, and if it can, the ingestion change that stops zeroing someone's daily total", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "an 84MB upload fails for one customer with a 413 after forty seconds, and there are five different size limits in the path. find which one it is, then switch that route to the presigned upload path we already have", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "go services each define their own Ticket type and convert at every boundary", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "ingest path should detect and record counter resets rather than clamping the difference to zero", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "clause list needs a confidence indicator", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "queue panel clips at 125% text", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "three hardware partners integrate against our MQTT contract from a PDF written in 2024, and the behaviours they get wrong — retained state surviving an offline hub, non-idempotent commands, duplicates under QoS 1 — are the ones we never wrote down. write the integration reference properly, with those three as prominent sections rather than footnotes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "is our match quality metric measuring anything once the window is uncapped", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "a walkthrough of how a command reaches a device would help before i touch the ack path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "smart plugs report energy readings that jump backwards, which corrupts the daily totals:\n\ndevice plug_4471, cumulative energy Wh:\n 10:00 128,441\n 10:15 128,502\n 10:30 128,560\n 10:45 61,204 ← jump backwards\n 11:00 61,290\n 11:15 61,344\n\nfirmware notes: the counter is a u32 of deciwatt-hours stored in flash, written every 15 minutes, and the device reboots on OTA or brownout\nour ingestion computes daily total as last_reading - first_reading of the day", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "die Automationen feuern doppelt, seit wir die Regel-Engine neu ausgerollt haben:\n\n2026-07-29T18:00:00.114Z rule r_4471 triggered (schedule 18:00) → action: turn_on lamp_881\n2026-07-29T18:00:00.118Z rule r_4471 triggered (schedule 18:00) → action: turn_on lamp_881\n2026-07-29T18:00:00.412Z device lamp_881 state=on\n2026-07-29T18:00:00.418Z device lamp_881 state=on\n\nzwei Instanzen der Engine laufen seit dem Rolling-Update, beide lesen denselben Zeitplan aus Postgres und es gibt keine Sperre; die alte Instanz sollte nach 30 Sekunden beendet werden, hängt aber an einer offenen MQTT-Verbindung", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "de"}
{"prompt": "hub fleet runbook should be a page rather than tribal knowledge, and the broker restart that disconnects four hundred thousand devices deserves a confirmation prompt. write the runbook, then add the guard", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "our on-call runbook for the hub fleet is two lines. what the team actually does:\n\n- \"hubs offline\" is almost always the ingest broker, not the hubs; check broker connection count first\n- a broker restart disconnects 400,000 hubs which then reconnect within 60 seconds — do not do this at peak\n- individual hubs stuck offline are usually the publish deadlock; a remote reboot command won't reach them\n- the OTA rollout must be paused before any broker work, otherwise devices update mid-disconnect\n- `hubctl fleet pause-ota` is the command, and it takes about two minutes to take effect\n- if energy readings stop for a region, check the ingest partition lag before assuming devices are down\n\nwrite the runbook page, in the order a person paged at 3am would need it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "the legal customer's data requirements, which now block a renewal:\n\n\"Documents must be processable within our tenancy, with no document content transmitted to a third-party model provider. Where a provider is used, content must not be retained beyond the request and must not be used for training, evidenced contractually. Partial extraction results must not be persisted if extraction fails. Employee access to document content must be logged with a reason and reviewable by us. Deletion must propagate to all derived artefacts including embeddings and logs within 30 days.\"\n\nwe send full documents to a provider, persist partial results, log document text in our own application logs, and have never traced embeddings on deletion. i want the plan by contractual risk", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "device event handling is a match with a branch per device type, inline debounce logic in two of them, and a silent catch-all that hid a new device type for a month. restructure it into a handler per type with shared debounce and validation, and make an unknown type a loud failure rather than a shrug", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "matchmaking in eu-west stalls at every peak because a live event left the relaxation cap and backfill timeout disabled, but the deeper problem is that our pool scan is quadratic and nobody noticed until the region grew. i want a view on the algorithm itself, not just the config, with the party-matching path's bucketing as the obvious starting point", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "our matchmaker config across regions, and only eu-west stalls:\n\n# na-east\npool_scan_interval: 500ms\nmax_pool_size: 20000\nbackfill_timeout: 60s\nrelaxation_step: 100\nrelaxation_cap: 800\nscan_workers: 8\n\n# eu-west\npool_scan_interval: 500ms\nmax_pool_size: 100000\nbackfill_timeout: 0 # disabled last week for a live event\nrelaxation_step: 100\nrelaxation_cap: 0 # uncapped, also from the live event\nscan_workers: 8\n\nand the two regions' shapes at peak:\n\n na-east pool 18,400 scan 42ms matches 118/s backfills active 41\n eu-west pool 96,200 scan 8,400ms matches 0/s backfills active 1,204\n ap-south pool 11,900 scan 31ms matches 74/s backfills active 22\n\nthe eu-west values were set for a live event three weeks ago and the ticket to revert them is still open", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "the partner hardware spec we have to implement on the cloud side:\n\nthe partner's devices speak their own protocol to their own cloud, and we integrate cloud-to-cloud:\n POST /partner/v1/webhook they call us on every state change, HMAC-SHA256 signed, at most 50/s per account\n GET /partner/v1/devices we poll for the device list every 6 hours; it is not paginated and returns up to 40k devices\n POST /partner/v1/command we send commands; they respond 202 and deliver asynchronously with no completion callback\n their state changes can arrive out of order and they do not include a sequence number, only a timestamp with second precision\n a device removed on their side simply stops appearing in the device list\n they rate limit us to 10 requests per second and will not raise it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "device state ownership needs deciding and the reconciliation path needs building either way. work through the model with me, then implement the reconnect reconciliation so hubs returning after days stop overwriting newer cloud state", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "hub fleet spans four firmware versions and we've never deprecated one", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "what guarantees does the matchmaker make that a ticket eventually matches at all", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "extraction service has three HTTP clients with three timeout and retry policies, and the one used for model calls is the one with no timeout at all. consolidate them, and tell me which current behaviour each caller was relying on before i sign off on a single policy this is the third time it's bitten us and i'd like it to be the last.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "matchmaking operator guide is one command, while the real knowledge — that queue depth is the wrong signal, that killing a backfill is safe, that restarting drops every ticket — lives in two people's heads. write the guide ordered by what someone paged during a peak needs first it doesn't have to be elegant, it has to be defensible in a review.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "so our extraction pipeline's cost tripled with no change in volume:\n\nweek 29: 412k documents, 8.1M model calls, $12,400\nweek 30: 409k documents, 24.8M model calls, $38,100\n\ncall breakdown by stage:\n classifier 409k → 409k\n extractor 2.4M → 2.4M\n validator 5.3M → 22.0M\n\nthe validator retries on a schema mismatch, up to 5 times, and we changed the schema on monday to add a required field the model rarely produces", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "session tokens for the mobile app expire early for some users and they get logged out mid-automation:\n\ntoken issued: 2026-07-29T09:00:00Z, exp 2026-08-28T09:00:00Z (30d)\nrejected at: 2026-07-29T14:12:44Z with \"token expired\"\n\nauth service log:\n jwt validation failed: token used before issued (iat 1753837200, now 1753818764)\n node: auth-7d9c4f8b6-x2plq\n\nntp status on that node: offset -18436 seconds, last sync 41 days ago\n\nthree of our twelve auth nodes have drifted, and the app retries against a random node until one accepts", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ok so our validator's retry loop, which apparently tripled the bill:\n\ndef validate(doc, extracted, schema, attempts=5):\n for i in range(attempts):\n try:\n return Schema(schema).validate(extracted)\n except ValidationError as e:\n extracted = call_model(\n REPAIR_PROMPT.format(errors=e.messages, text=doc.text, previous=extracted)\n )\n log.warning(\"validation failed after %d attempts\", attempts)\n return extracted\n\nthe repair prompt includes the full document text, the schema now has a required field the model rarely produces, and there's no check for whether the repair actually changed anything", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "here's the matchmaking relaxation schedule, which i inherited and don't trust:\n\nfunc (t *Ticket) SkillWindow(now time.Time) int {\n age := now.Sub(t.CreatedAt)\n steps := int(age.Seconds()) / 30\n return baseWindow + steps*100\n}\n\nfunc (m *Matchmaker) scan(pool []*Ticket) []Match {\n for i := range pool {\n for j := i + 1; j < len(pool); j++ {\n if compatible(pool[i], pool[j], time.Now()) { ... }\n }\n }\n}\n\nno cap on the window, the scan is quadratic in pool size, and compatible() calls SkillWindow for both tickets on every comparison", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "por favor, revisa el manejo del contador de energía antes de que lo desplieguemos:\n\nfn daily_total(readings: &[Reading]) -> u64 {\n let first = readings.first().map(|r| r.wh).unwrap_or(0);\n let last = readings.last().map(|r| r.wh).unwrap_or(0);\n last.saturating_sub(first)\n}\n\nel contador es un u32 en el firmware, se reinicia a cero tras un OTA o un corte de corriente, y el dispositivo puede enviar lecturas fuera de orden tras una reconexión; saturating_sub devuelve cero cuando hay un reinicio, así que el consumo de ese día simplemente desaparece", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "es"}
{"prompt": "honestly the OTA design doc, written before we had the field failures. does it still hold?\n\n## Update flow\nThe hub downloads the image to slot B, verifies the signature, writes the boot flag and reboots. If slot B fails to boot, the bootloader falls back to slot A.\n\n## Assumptions\n- Slot A always holds a known-good image.\n- The boot flag can be written independently of the slots.\n- A failed update costs a reboot, not a device.\n\n## Not covered\nPower loss during the flag write. Devices whose slot A has itself been updated in place. Recovery without physical access.\n\nwe now know the flag shares a flash sector with the tail of slot B, and about one device in two hundred does not come back", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "right, the query behind our device history screen, which is slow for anyone with more than fifty devices:\n\nSELECT d.id, d.name, d.kind, d.last_seen_at,\n (SELECT state FROM device_states s WHERE s.device_id = d.id ORDER BY s.at DESC LIMIT 1) AS current_state,\n (SELECT count(*) FROM device_events e WHERE e.device_id = d.id AND e.at > now() - interval '24 hours') AS events_24h,\n (SELECT sum(wh) FROM energy_readings r WHERE r.device_id = d.id AND r.at::date = current_date) AS energy_today\nFROM devices d\nWHERE d.home_id = $1\nORDER BY d.name;\n\ndevice_states is 4.1 billion rows, device_events 8.8 billion, energy_readings 12 billion, all partitioned by day", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "quick one — the backfill logic in matchmaking, which i think is why the pool never drains:\n\nfunc (m *Matchmaker) backfill(match *Match) {\n for len(match.Players) < match.Mode.Size {\n ticket := m.pool.FindBest(match) // scans the whole pool\n if ticket == nil {\n time.Sleep(500 * time.Millisecond)\n continue // no timeout, no give-up\n }\n match.Add(ticket)\n m.pool.Remove(ticket)\n }\n}\n\nbackfills hold a slot in the match and are counted as active; there are 1,204 of them in eu-west right now and each one scans the pool twice a second", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the energy dashboard complaints, which need to become a help article:\n\n- daily totals occasionally show zero or a wildly wrong number\n- this happens when a plug reboots, because the cumulative counter restarts at zero\n- our daily total is last minus first, so a reboot mid-day either zeroes it or produces a negative we clamp to zero\n- the plug's own counter also wraps at about 4.2 million Wh, which affects a handful of long-running devices\n- customers see this as \"the app forgot my electricity usage\" and some have asked for refunds\n- the underlying readings are all still there; only the daily aggregation is wrong\n\nwrite the help article, and separately tell me which of these is a data problem and which is a presentation problem", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from the bricked hubs, and we owe affected customers an explanation:\n\n09:02 first reports of hubs not coming back after the 4.2.1 update\n10:15 confirmed: 41 devices out of 8,400 updated overnight are unresponsive\n11:40 cause identified: the boot flag shares a flash sector with the tail of slot B\n12:00 OTA rollout paused for all remaining devices\n14:30 recovery requires physical access and a serial cable, which customers do not have\n16:00 decision: replace affected units, 41 devices across 38 customers\n\nthe customers are consumers, the hub controls their heating, and several were without it overnight\n\nwrite the customer notification and a separate internal write-up for the hardware team", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "as notas da revisão da pipeline de extração, para transformar em documento de decisão:\n\n- o validador repete até cinco vezes quando o esquema não valida, e cada repetição envia o documento inteiro\n- a alteração de segunda-feira tornou obrigatório um campo que a maioria dos contratos não tem\n- o custo semanal triplicou sem aumento de volume\n- opções: tornar o campo opcional, deixar o validador desistir mais cedo, ou enviar apenas o excerto relevante na repetição\n- a equipa jurídica quer o campo obrigatório porque alimenta um relatório\n- ninguém mede a taxa de sucesso das repetições, portanto não sabemos se ajudam\n\nescreve a nota de decisão com as opções, os custos estimados e uma recomendação", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "pt"}
{"prompt": "fyi the questions our legal customer's security team sent, which need answering as a document:\n\n\"Which parts of a document are sent to the model provider, and is any of it retained by them? Can we run in a mode where documents never leave our tenancy? What happens to a document if extraction fails partway — is a partial result stored? Who at your company can read the contents of an uploaded document, and is that access logged? If we delete a document, is it removed from your model provider's logs as well? Do you use customer documents to improve any model?\"\n\nanswer each from the code and our contracts, and write it as a page we can publish rather than a mail thread", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "heads up: the matchmaking service's operator guide is a single command. reality:\n\n- queue depth over 10,000 in one region means the scan is falling behind, not that players are queueing\n- `mmctl pool stats <region>` shows the pool size and scan duration, which is the actual signal\n- backfills are counted as active matches and can starve the pool; `mmctl backfill list` shows them\n- killing a backfill returns its players to the pool, which is safe and is usually the fix\n- restarting the matchmaker drops every ticket, which players experience as being kicked from the queue\n- the relaxation schedule has no cap, so a stuck ticket eventually matches with anyone, which is worse than not matching\n\nwrite the operator guide, ordered by what someone paged during a peak would need", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "社内向けに、モデル呼び出しの運用ドキュメントがありません。現状はこうです:\n\n- 抽出は 1 文書につき最大 3 回モデルを呼ぶ（分類・抽出・検証）\n- 検証が失敗すると最大 5 回まで修復プロンプトを送る。修復プロンプトには文書全文が含まれる\n- タイムアウトは 120 秒、リトライは 3 回、指数バックオフなし\n- レート制限に当たった場合は 429 をそのまま上位に返しており、キュー全体が詰まる\n- コストの計測はバッチ単位でしかできず、顧客別・ステージ別の内訳が出せない\n- プロンプトはコードに直接埋め込まれていて、変更履歴はコミットログにしかない\n\n例:\n\nresp = client.messages.create(model=MODEL, max_tokens=4096,\n messages=[{\"role\": \"user\", \"content\": prompt}])\n\nこれを社内の開発者向けドキュメントとしてまとめてください。特にリトライとコストの扱いを明確に\n\n実際のコストの内訳（先週）:\n classifier 409,000 calls $1,100\n extractor 2,400,000 calls $9,800\n validator 22,000,000 calls $27,200\n\n retry_on_429_total = 41,882\n timeout_total = 1,204\n repair_attempts_p99 = 5 (上限)\n\nこの内訳は手作業で集計したもので、ダッシュボードには存在しません", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "ja"}
{"prompt": "clippy on the hub firmware, and one of these is the deadlock:\n\nwarning: this `MutexGuard` is held across an `await` point\n --> src/mqtt.rs:88:9\n |\n88 | let mut client = self.client.lock().await;\n = help: consider using an async-aware lock or restructuring\nwarning: large enum variant\n --> src/proto.rs:41:1\nwarning: casting `u32` to `u16` may truncate\n --> src/energy.rs:141:22\nwarning: this loop never actually loops\n --> src/ota.rs:22:5\nwarning: `saturating_sub` on values that may legitimately decrease\n --> src/energy.rs:66:20\n\n5 warnings, and mqtt.rs:88 is exactly where hubs wedge", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "ruff and mypy on the extraction service, gate goes on next sprint:\n\nservices/extract/validator.py:41: error: Argument \"schema\" has incompatible type \"dict[str, Any]\"; expected \"Schema\" [arg-type]\nservices/extract/validator.py:88: warning: B008 Do not perform function call in argument defaults\nservices/extract/pipeline.py:141: error: Missing return statement [return]\nservices/extract/prompts.py:22: warning: E501 line too long (412 > 100)\nservices/extract/client.py:66: error: Call to untyped function \"call_model\" in typed context [no-untyped-call]\n\n3 errors, 2 warnings, and the missing return is in the path that handles a rate limit", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "small thing but the CDN and origin limits for uploads, one of these is why an 84MB file fails:\n\ncdn (eu endpoint): max request body 50MB\nnginx: client_max_body_size 100m\ningress annotation: nginx.ingress.kubernetes.io/proxy-body-size: 100m\napp: MAX_UPLOAD_BYTES = 104857600\ns3 presign (unused): part size 8MB, unlimited total\n\nthe presigned upload path exists in the code, is tested, and is not used by the web client\n\nand the sizes we actually see:\n p50 upload 1.2 MB\n p95 upload 18 MB\n p99 upload 62 MB\n largest last month 340 MB (rejected)\n\nabout 4% of uploads from that one customer are over the CDN's 50MB limit, and they are the contracts with scanned exhibits attached, which are the ones the customer cares most about", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "not urgent, but the hub's kubernetes ingest deployment, which we restarted during peak by accident:\n\nreplicas: 6\nstrategy:\n type: RollingUpdate\n rollingUpdate: { maxSurge: 1, maxUnavailable: 1 }\nterminationGracePeriodSeconds: 30\nreadinessProbe: { httpGet: { path: /healthz, port: 8080 }, periodSeconds: 5 }\nlifecycle:\n preStop: { exec: { command: [\"sleep\", \"5\"] } }\n\neach pod holds about 70,000 MQTT connections, hubs reconnect immediately with a one second backoff, and a rolling update currently drops a sixth of the fleet at a time", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "les seuils d'alerte du parc de hubs, on nous réveille pour rien :\n\n- alert: HubsOffline\n expr: sum(hub_connected == 0) > 1000\n for: 1m\n labels: { severity: page }\n\n- alert: IngestLag\n expr: kafka_consumergroup_lag{group=\"telemetry\"} > 100000\n for: 5m\n labels: { severity: page }\n\n- alert: OtaFailures\n expr: increase(ota_failed_total[1h]) > 10\n for: 0m\n labels: { severity: ticket }\n\nen réalité : mille hubs hors ligne c'est du bruit sur quatre cent mille appareils ; le lag dépasse 100 000 à chaque redémarrage du broker ; et les 41 appareils briqués n'ont produit qu'un ticket, vu le lendemain matin", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "fr"}
{"prompt": "dependabot on the extraction service, and one is a CVE:\n\npydantic 2.7.1 → 2.9.2 (minor; validation error message format changed, our repair prompt parses it)\nanthropic 0.34.0 → 0.40.0 (minor; streaming API changes, we don't stream)\npillow 10.3.0 → 10.4.0 (CVE-2026-10118, buffer overflow in TIFF decoding)\npytesseract 0.3.10 → 0.3.13 (minor)\n\nwe pass scanned TIFFs through pillow before OCR, and our repair prompt includes the raw pydantic error text", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "this pipeline module does orchestration, retries, cost accounting and prompt assembly in one file:\n\nclass ExtractionPipeline:\n def run(self, doc):\n # ocr, with its own retry loop\n # layout model call, with a different retry loop\n # chunking, with the chunk size hardcoded per document type\n # extraction call, with prompt assembled inline from three f-strings\n # validation with the repair loop\n # cost accounting by summing token counts into a module-level dict\n # audit row written at the end, or not at all if anything raised\n\n700 lines, one test that mocks the model client and asserts on the final output", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "unsere Prompt-Bausteine liegen an vier Stellen im Code:\n\n# prompts.py\nEXTRACT_PROMPT = \"Extract all clauses...\"\n\n# pipeline.py\nprompt = f\"{EXTRACT_PROMPT}\\n\\nDocument type: {doc.kind}\\n{text}\" # zusätzlicher Kontext inline\n\n# validator.py\nREPAIR_PROMPT = \"The following JSON failed validation...\" # eigene Formatierung\n\n# experiments/ab_test.py\nPROMPT_V2 = \"...\" # läuft für 10% der Kunden\n\nvier Varianten, keine Versionierung, und niemand kann sagen, welcher Prompt ein bestimmtes Ergebnis erzeugt hat", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "de"}
{"prompt": "quarter planning input, needs sequencing:\n\n- 41 bricked hubs are a product recall problem and the fix needs a bootloader update first\n- the publish deadlock takes hubs offline until a power cycle and affects maybe 2% of the fleet monthly\n- extraction costs tripled and finance has noticed\n- eu-west matchmaking stalls at every peak since the live event config was left in place\n- the legal customer's security questionnaire is blocking a renewal worth a fifth of that product's revenue\n- one firmware engineer, one platform engineer, and the game backend team is two people\n- there's a hardware partner integration due in october that assumes our MQTT contract doesn't change", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, and i want the thinking before anyone starts:\n\nIOT-540 — Device state ownership\nDevice state currently lives in three places: the hub's memory, a retained MQTT message, and our postgres. They disagree routinely and support has learned to check all three. The proposal is a single authoritative state store with the retained message as a cache. Concerns: hubs go offline for days and must reconcile on reconnect; the automation engine reads state on every rule evaluation and cannot tolerate a database round trip; retained messages are what partner integrations read; and any change to the MQTT contract affects three hardware partners with their own release cycles.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the document review screen, which lawyers use for hours at a time:\n\nReview screen\n- Document pane on the left with the original scan, extracted clauses highlighted in place, and page thumbnails.\n- Clause list on the right, grouped by type, each showing a confidence indicator and the page it came from.\n- Clicking a clause scrolls both panes; the highlight must survive zoom and rotation.\n- Low-confidence extractions are marked with a shape as well as a colour and sort to the top of their group.\n- Editing a clause's text or type is inline, saves optimistically, and records who changed what.\n- A \"nothing extracted for this section\" state exists and must be visible rather than an absence.\n- Keyboard: j/k moves between clauses, e edits, a accepts, r rejects — lawyers ask for this specifically.\n- Must remain usable at 200% zoom for accessibility, which the current fixed two-pane layout does not.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings for the game's in-client store and queue UI, from a platform certification review:\n\n1. The queue timer is announced continuously by the screen reader, making the client unusable while queueing.\n2. Match-found accept is a 10 second timed action with no way to extend it, which fails the platform's timing requirement.\n3. Store prices are conveyed with strikethrough only for discounts, with no text alternative.\n4. Controller focus is lost when a modal closes, landing on the first element of the page rather than the invoking control.\n5. The rank badge conveys tier by colour alone.\n6. Text scaling above 125% clips the queue panel.\n7. No captions for the voice announcements in the match-found flow.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the home app's device screens actually use:\n\ntokens:\n color.surface #FFFFFF / #0D1117\n color.text #0D1117 / #E6EDF3\n color.muted #6E7781\n color.on #1A7F37\n color.off #6E7781\n color.warn #9A6700\n space 4/8/12/16/24, radius 8/12/20, touch target 44dp minimum\n type: title 20/26, body 15/22, caption 13/18\n\nthe device screens: six hardcoded colours including two greens, touch targets of 32dp on the toggle rows, an offline state shown only by reduced opacity, and three type sizes not in the scale\n\nbring it onto the tokens, fix the touch targets, and give offline a proper indicator", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "relaxation cap back to 800 in eu-west", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "pillow CVE bump before friday", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "onboarding email says \"you're hub\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "backfill timeout back to 60 seconds", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "pause the OTA rollout now", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "la app muestra vatios en vez de kilovatios", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "es"}
{"prompt": "maxUnavailable 1 drops 70k connections", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "make termination_notice_days optional", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "ntp is 41 days stale on three auth nodes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "OtaFailures should page immediately", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "Upload über presigned URLs statt Proxy", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "de"}
{"prompt": "hub telemetry is signed using the device's own clock, which on a hub that boots without network is whatever it was when it last had one, so the signature is valid and the timestamp is nonsense. work out how far back this goes in the stored data, then move to server-assigned time with the device clock kept only as a hint", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "our matchmaking pool is scanned three different ways depending on the code path:\n\n// scan.go — the main loop, quadratic over the whole pool\nfor i := range pool { for j := i+1; j < len(pool); j++ { ... } }\n\n// backfill.go — FindBest, linear scan per call, called twice a second per backfill\nfunc (p *Pool) FindBest(m *Match) *Ticket { for _, t := range p.tickets { ... } }\n\n// party.go — party matching, builds a map by skill bucket then scans buckets\nbuckets := map[int][]*Ticket{}\n\nonly the party path uses buckets; the other two ignore them entirely and rebuild nothing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "the schema we agreed for prompt versioning, now it needs building:\n\nCREATE TABLE prompt_versions (\n id uuid PRIMARY KEY,\n name text NOT NULL,\n version int NOT NULL,\n template text NOT NULL,\n schema jsonb,\n model text NOT NULL,\n params jsonb NOT NULL,\n created_by text NOT NULL,\n created_at timestamptz NOT NULL DEFAULT now(),\n UNIQUE (name, version)\n);\n\nevery model call records the prompt_version id it used; versions are immutable once referenced; an A/B experiment references two versions and the assignment must be recorded per document; and we need to answer \"which prompt produced this extraction\" for any result in the last two years", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "device screens ignore the tokens and use 32dp touch targets on the toggles. bring them onto the tokens and fix the targets, and tell me whether the row height change breaks the compact layout on small phones", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "missing return in the rate limit path", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "test run button on the automation editor", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "toggle rows are 32dp, should be 44", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "rank badge is colour-only", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "j and k through the clause list", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "オフラインの機器が薄い色でしか分かりません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "ja"}
{"prompt": "controller focus lost after a modal", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "skill buckets for every scan path", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "une seule machine à états pour le hub", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "fr"}
{"prompt": "`last_seen_at` naming everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "extract the repair loop from validate", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "inline `compatible`, one caller left", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "one retry policy for model calls", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "doc comments on the MQTT topic contract", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "changelog for firmware 4.2.2", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "nota aos clientes sobre os hubs afetados", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "pt"}
{"prompt": "document the retained-state gotcha", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the state-ownership proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the deadlock fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "can a backfill starve the pool?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "¿el validador reintenta con el documento entero?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "es"}
{"prompt": "walk me through the OTA flow", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "hubs wedge until power cycled", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "warum feuern die Automationen doppelt?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a document's extraction lineage", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "carry on with that", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "cheaper, ideally", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "you choose what matters", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo de la extracción, continúa", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "es"}
{"prompt": "tidy where you can", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "like the last one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "security answers", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "low risk only today", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "take a look please", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "やり方はお任せします", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "ja"}
{"prompt": "forty-one hubs are bricked in customers' homes and the fix needs a bootloader update that itself has to go over the air, which is exactly the mechanism that failed. i want the recovery plan worked through properly — how we ship a bootloader safely, what we do for the devices already dead, and what we change so a partial flash write can never take a device out again", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "legal customer's renewal is blocked on data handling we don't currently do: no third-party model provider, no persisted partial results, no document text in logs, and deletion propagating to embeddings. i'd like the options with honest costs, including the one where we run a model in our own tenancy and what that does to quality and latency", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "OTA design doc assumes the boot flag can be written independently of the slots and that a failed update costs a reboot rather than a device, both of which we now know are false. read it against the flash layout and the bootloader and tell me which of its other assumptions are similarly wrong the last person who touched this left, so there's nobody to ask.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "matchmaking pool is scanned three ways — quadratic in the main loop, linear per backfill, bucketed only in the party path — and the bucketing is the one that works. bring all three onto the bucketed structure, keep match quality measurably the same on a replayed peak, and make the scan cost sublinear in pool size", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "prompts live in four places including an experiment file that runs for a tenth of our customers, and nobody can say which prompt produced a given result. consolidate them into one versioned location, record the version on every call, and keep the experiment running throughout the migration we've been burned by guessing at this before, so evidence over instinct please.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "automation editor is where users spend their time and it currently lets you build automations that can never fire, then tells you nothing. build it to the spec — inline impossible-condition warnings, device state next to actions, and the test run button people keep asking for if the answer is that it's fine as it is, that's a useful answer too.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "review screen is a fixed two-pane layout that breaks at 200% zoom, which fails the accessibility requirement in a public sector tender. rebuild it to the spec with the keyboard navigation lawyers asked for, and make sure the clause highlighting survives zoom and rotation keep it concrete — file names and line numbers are more use than principles here.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "before we change the OTA flow i want the failure modes written down — power loss at each step, a corrupted slot, a bootloader that itself needs updating — and then the flag relocation implemented against that analysis this has come up in three separate reviews now and never gets done.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "model cost control needs a design — budgets per stage, a circuit breaker, attribution per customer — and the repair loop needs fixing this week regardless. give me the design, then change the repair prompt to send only the failing section", "purpose": "planning", "secondary": "quickFix", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "unser Matchmaking skaliert nicht mehr und die Konfiguration aus dem Live-Event steht immer noch. Ich hätte gern zuerst ein Konzept für die Poolstruktur und danach die Umstellung des Haupt-Scans auf Buckets", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "de"}
{"prompt": "MQTT integration reference has to exist before the october partner starts, and while writing it please confirm whether a redelivered command really does execute twice, because two partners have asked and we've given different answers", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "model-call guide needs writing and i expect it will surface things we should fix rather than document — the 429 propagation especially. write the guide, and give me that list separately", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "our device event handling has grown a branch per device type:\n\nmatch event.kind {\n \"plug.energy\" => { /* 40 lines, includes counter reset detection */ }\n \"plug.state\" => { /* 20 lines */ }\n \"thermostat.temp\" => { /* 30 lines, has its own smoothing */ }\n \"thermostat.setpoint\" => { /* 25 lines */ }\n \"sensor.motion\" => { /* 15 lines, debounce logic inline */ }\n \"sensor.contact\" => { /* 15 lines, different debounce */ }\n \"lock.state\" => { /* 35 lines, includes an audit write nothing else does */ }\n _ => { /* silently ignored, which is how we missed a new device type for a month */ }\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "the hub thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "escribe la guía del operador para el matchmaking y comprueba en el código si matar un backfill devuelve realmente a los jugadores a la cola, porque el runbook lo afirma y nadie lo ha verificado", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "three online checks for devices should become one, and i'd like to know which of the three the automation engine should actually be using before we standardise on it. check that, then unify", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "tokens are being rejected as \"used before issued\" on three auth nodes whose clocks have drifted by five hours. confirm that's the whole story, then fix the nodes and make the validator tolerate a small skew rather than failing outright a rough ordering matters more to me than a complete answer right now.", "purpose": "debugging", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "players are being matched against wildly stronger opponents and the relaxation window is my suspect, but i want it confirmed against real tickets. diagnose it, then cap the window at whatever the analysis supports", "purpose": "debugging", "secondary": "quickFix", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "store and queue UI fails platform certification on seven counts including a timed accept with no extension. fix what we can before submission, and write the certification response for the rest", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "prompt versioning needs the immutability rules agreed before it's built — what happens when someone edits a referenced version, and how experiments map to versions. settle that, then implement the table and the recording", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "rename `Ticket.Skill`, it's a rating in one place and a percentile in another", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain what happens to a retained state message when a hub is factory reset", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand how a document that fails extraction halfway is stored, if at all", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "why does the layout model still run now that OCR quality has improved", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "someone should check whether document text ends up in our application logs", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that a hub keeps executing automations while disconnected from the cloud", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment le compteur d'énergie gère un redémarrage du boîtier ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/ota.md describes a rollback that the bootloader doesn't actually implement", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a short note on why prompts are moving into the database, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "partner changelog needs an entry for the command ack topic changing shape", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "rustdoc on publish() promises a 30 second bound that the lock acquisition ignores", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer note about energy totals being recalculated for the affected days", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "health endpoint reports the matchmaker healthy while it has created no matches for ten minutes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "staging has one hub and prod has four hundred thousand, with the same broker connection limits", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "how should we handle a hardware partner whose devices we can't update ourselves", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to evaluate an extraction change when the ground truth is a lawyer's judgement", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether automations should run on the hub or in the cloud", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "two customers want an on-premise deployment of the document pipeline, what would that require", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "we need a plan for supporting a second matchmaking mode with completely different team sizes", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to a queued player when their region's matchmaker restarts", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns a hub's last twenty state transitions, for support", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "per-customer cost attribution for model calls, since finance can only see the total", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "commands need an idempotency key so a redelivery after a missed ack doesn't run twice", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "device list needs a filter for offline devices, which is what people open the app to check", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "clause list should let a reviewer accept a whole group at once, with undo", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "queue screen should show estimated wait time rather than a spinner that lies", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "energy chart should mark counter resets rather than drawing a cliff", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "whatever unblocks the renewal", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "next bit of the firmware work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "mobile app and the hub disagree about what \"away mode\" means — one treats it as a mode, the other as a flag that other automations can clear — and users notice when heating comes back on. settle the semantics, then make both sides agree, and tell me which behaviour existing automations depend on whatever you find, write it somewhere the next person will actually look.", "purpose": "refactor", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "python services load secrets three different ways and one of them logs the loaded values at debug level, which is on in staging. fix that today, then unify the loading so it can't happen again", "purpose": "quickFix", "secondary": "refactor", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "extraction queue has no dead letter, so a document that fails five times is retried forever and one bad scan has been cycling since tuesday. add the dead letter, and decide with me first what a human is supposed to do with the documents that land in it i'm not attached to the current approach if there's an obviously better one.", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "internal page on the hub's state machine doesn't exist, which is why every firmware bug report starts with three people describing the states differently. write it from the code — the four atomics, who sets what, and what the watchdog does with each combination — as the reference for the rework context if it helps: this has been open since before i joined the team.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "hub reports its firmware version only on connect, so a device that failed an update and rolled back looks like it's still on the old version forever, which is how we undercounted the bricked devices. report the running version on every state message, and backfill what we can from the OTA logs i'd rather have the reasoning written down than a quick answer.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "go services each define their own Ticket type and convert at every boundary, which is why the matchmaker and the party service disagree about whether skill is a rating or a percentile. define it once in a shared package, convert only at the edges where we talk to clients, and prove that a replayed peak produces identical matches", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "validator's repair loop, the OCR retry and the model client's own retry are three nested layers of retrying that nobody designed together, and a single bad document can therefore produce seventy-five model calls. flatten them into one retry policy with an overall budget per document, keeping the successful-path behaviour exactly as it is", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "chunk sizes are hardcoded per document type in the pipeline, the layout model has its own idea of section boundaries, and the extractor gets whichever wins. pull chunking into one place with the document type as a parameter, and keep the extraction output identical for a sample of a thousand documents across all types tell me if this is the wrong shape entirely, i won't be offended.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "hub's flash layout, the bootloader's expectations and the OTA writer's assumptions live in three files that have to agree and don't. bring the layout into one definition both the bootloader and the application build from, and make a mismatch a compile error rather than a bricked device nobody has trusted this code for about a year, which is part of the problem.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me what our match quality metric actually measures once the relaxation window is uncapped, because it compares against the window rather than against the players' skills. read the metric and the matcher together and tell me whether the number we report weekly means anything at all assume whoever picks it up next has no context beyond what you write.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "eu-west matchmaker still runs the live-event configuration from three weeks ago — no relaxation cap, no backfill timeout, a pool five times the size of any other region. put the standard values back, and tell me which of the three actually mattered so we know what the event genuinely needed the sooner we know roughly how big this is, the better for planning.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "ingest deployment does a rolling update with maxUnavailable of one, which drops seventy thousand MQTT connections at a time and produces a reconnect storm that looks exactly like an outage. change the rollout to something the fleet can absorb, and tell me what the safe reconnect rate actually is i've already spent an afternoon on it and got nowhere useful.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt":"diff --git a/projects/meridian/Sources/CLI/Commands/Doctor.swift b/projects/meridian/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/meridian/Sources/CLI/Commands/Doctor.swift\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 MeridianTideWorkerFlow'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":"projects/meridian/workers/thumbnail/consumer.ex 里的 MeridianGarnetModalStore 最近在 SQLite 流程中出现间歇性问题。 原因已经明确：只把 staging timeout 从 15 秒改成 30 秒，并调整对应 assertion。\n\n约束：\n- 继续使用 SQLite\n- 保持兼容性和取消语义\n- 改动只限于 MeridianGarnetModalStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"zh"}
{"prompt":"Quartz: // projects/meridian/apps/console/routes/usage.svelte\nfinal class MeridianFlintTimelineFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nRestructure MeridianFlintTimelineFlow 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":"Three teams extended MeridianVelaDrawerService independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current PostgreSQL 17 operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS 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":"MeridianDeltaCanvasService's staging timeout is already known to be wrong: change the single projects/meridian/db/migrations/20260730_events.sql value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Raven: // projects/meridian/app/src/main/SyncWorker.kt\nfinal class MeridianOrbitSyncFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nRestructure MeridianOrbitSyncFlow 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":"MeridianCopperBridgeCoordinator needs a paired pass: change MeridianCopperBridgeCoordinator's known staging timeout from 15 to 30 seconds, plus capture the contract and rollback note for consumers. Use projects/meridian/db/migrations/20260730_events.sql as the source of truth, preserve the WebGPU contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Sable: // projects/meridian/infra/modules/edge/main.tf\nfinal class MeridianCloudReconcilerFlowCoordinator {\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 MeridianCloudReconcilerFlow; 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":"Compare the old and new MeridianDriftConsoleFlow 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":"Compare the old and new MeridianSableParserService 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":"Tide: // projects/meridian/packages/api/openapi.yaml\nfinal class MeridianFernSnapshotFlowCoordinator {\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 MeridianFernSnapshotFlow 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":"Since the last release, MeridianEchoRegistryService has shown an accessibility label that reads the internal enum; nobody on the team can reproduce it reliably on a laptop. Correlate the queue, scheduler, storage, and shutdown paths; form competing hypotheses, identify evidence for each, and narrow the root cause before proposing a code change.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing NATS JetStream deployment\n- keep the work scoped to MeridianEchoRegistryService and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Rename MeridianAtlasSearchService's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Center the MeridianBeaconStoreStore modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Bring MeridianOspreyJobStore's confirmation sheet in line with the design tokens, including destructive emphasis, dark appearance, Dynamic Type, and swipe-to-dismiss behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Move MeridianOpalRouterStore's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"MeridianDeltaCanvasCoordinator: ship a sensible version","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Walk through MeridianAcornWidgetService's features.py","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Match MeridianPineMetricsStore's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"MeridianNovaPickerCoordinator: polish the last piece","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Umbra: Incident timeline — INC-53159\n\n08:02 deploy MeridianKiteSchedulerCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nUsing this as the starting evidence, propose a staged MeridianKiteSchedulerCoordinator migration with compatibility seams, owners, canary metrics, rollback gates, and a no-code first milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"MeridianRainfallDBService crashes after reconnect","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Vela: projects/meridian/Sources/App/SessionStore.swift has grown through several launches, and MeridianAmberFilterStore now mixes policy, transport, persistence, and metrics in one place. Separate those responsibilities into focused units, remove the duplicated normalization branches, and keep public types, wire values, log fields, timing, and test-observable behavior exactly the same.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing NATS JetStream deployment\n- keep the work scoped to MeridianAmberFilterStore and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-53146: retire the legacy replay path for MeridianRavenSessionFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCapture the MeridianRavenSessionFlow 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":"boundary","lang":"en"}
{"prompt":"Ownership of MeridianMapleQueueStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. 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- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current SQLite operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS 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":"Willow: # projects/meridian/internal/auth/refresh.go\n[worker.meridianmoonlitsdkflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.meridianmoonlitsdkflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.meridianmoonlitsdkflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.MeridianMoonlitSDKFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-53144\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/meridian/internal/auth/refresh.go and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Memory attributed to MeridianPrismCacheService rises after every cancelled import and never falls. Trace task ownership, buffers, and callbacks to identify what remains reachable.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: MeridianMosaicGridStore has one known configuration mistake in projects/meridian/ui/settings/PrivacyPane.tsx, not an open-ended failure investigation. 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- do not introduce another runtime dependency\n- stay compatible with the existing SQLite deployment\n- keep the work scoped to MeridianMosaicGridStore and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Bring MeridianBasilRunnerStore's confirmation sheet in line with the design tokens, including destructive emphasis, dark appearance, Dynamic Type, and swipe-to-dismiss behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Xylem: Ticket OPS-53140: retire the legacy replay path for MeridianPrismCacheFlow\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 MeridianPrismCacheFlow 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":"MeridianCedarPolicyCoordinator needs a paired pass: finish MeridianCedarPolicyCoordinator's responsive empty and retry states, plus give the existing implementation a read-only safety pass. Use projects/meridian/web/components/FilterDrawer.vue as the source of truth, preserve the Tokio contract, and avoid unrelated cleanup.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"What is the safest way to split projects/meridian/app/src/main/SyncWorker.kt into independently owned modules while MeridianFlintTimelineStore's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"MeridianMicaProfileCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Support wants the behavior in projects/meridian/packages/api/openapi.yaml recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary. The deliverable is prose for consumers; do not alter the handler.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Pin MeridianCedarPolicyStore's Tokio dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"PM needs a concise migration note for MeridianEmberRelayStore, 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":"Move MeridianNimbusFormService's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Security flagged MeridianAtlasSearchStore for a read-only pass because its Tokio boundary mixes tenant data, retries, and cancellation in subtle ways. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current Tokio operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"MeridianRavenSessionCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"MeridianCinderAuthStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/meridian/web/components/FilterDrawer.vue and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The MeridianOpalRouterService surface in projects/meridian/app/src/main/SyncWorker.kt is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Read projects/meridian/internal/auth/refresh.go and tell me whether MeridianCloudReconcilerStore 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":"diff --git a/projects/meridian/internal/auth/refresh.go b/projects/meridian/internal/auth/refresh.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/internal/auth/refresh.go\n+++ b/projects/meridian/internal/auth/refresh.go\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate MeridianSlateEditorFlow'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":"Yarrow: Bring MeridianFlintTimelineService's confirmation sheet in line with the design tokens, including destructive emphasis, dark appearance, Dynamic Type, and swipe-to-dismiss behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Zephyr: diff --git a/projects/meridian/lib/codec/frame.cc b/projects/meridian/lib/codec/frame.cc\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/lib/codec/frame.cc\n+++ b/projects/meridian/lib/codec/frame.cc\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\nAdd the bounded MeridianPineMetricsFlow replay flow described here, including authorization, key rotation, cancellation, lag metrics, and tests for malformed and cross-tenant cursors.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Checkout: diff --git a/projects/meridian/src/sync/reconcile.ts b/projects/meridian/src/sync/reconcile.ts\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/src/sync/reconcile.ts\n+++ b/projects/meridian/src/sync/reconcile.ts\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 MeridianCopperBridgeFlow 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":"Draft MeridianAmberFilterService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Two asks around MeridianFernSnapshotCoordinator: (1) find the unknown cause of a feature flag whose default differs between environments; (2) give the existing implementation a read-only safety pass. Do not introduce another runtime dependency, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Polish the MeridianBeaconStoreService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"MeridianCoralUploadService est-il sûr ?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"fr"}
{"prompt":"MeridianMosaicGridService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Bring the drawer and detail pane to production polish with fluid sizing, honest skeletons, focus restoration, accessible announcements, and touch targets that survive large text.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current SQLite operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"MeridianAmberFilterCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-53150: retire the legacy replay path for MeridianLumenChartCoordinator\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 MeridianLumenChartCoordinator 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":"PM needs a concise migration note for MeridianMapleQueueFlow, including the user impact, rollback trigger, and the one configuration key operators must change. The deliverable is prose for consumers; do not alter the handler.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The MeridianLumenChartStore 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":"We expect MeridianLumenChartService to outgrow its current PostgreSQL 17 arrangement next quarter, but changing everything at once would be risky. 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- do not introduce another runtime dependency\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to MeridianLumenChartService and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"MeridianIrisBatchCoordinator is blocking the next release because timestamps rendered one day ahead near UTC midnight. I need two concrete outcomes from a single pass: change MeridianIrisBatchCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing PostgreSQL 17 conventions in projects/meridian/packages/api/openapi.yaml; do not introduce another runtime dependency. 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.6,"slice":"mixed","lang":"en"}
{"prompt":"MeridianRavenSessionStore's staging timeout is already known to be wrong: change the single projects/meridian/Sources/CLI/Commands/Doctor.swift value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"MeridianSableParserCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"# CI job 53133: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: SQLite\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] MeridianAsterWebhookFlowIntegration.replays_after_timeout ... ok\n[test] MeridianAsterWebhookFlowIntegration.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\nReconstruct the MeridianAsterWebhookFlow 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":"Lay out a two-milestone strategy for eliminating duplicate retries after a network handoff in MeridianEmberRelayFlow, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Assess the MeridianOrbitSyncService diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter MeridianAcornWidgetFlow\n RUN v3.2.4 /workspace/apps/console\n × MeridianAcornWidgetFlow > 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=53121 phase=resume storedCursor=seg-0183\n session=53121 phase=fetch requestCursor=seg-0183 pageSize=200\n session=53121 phase=commit receivedCursor=seg-0184 itemCount=0\n session=53121 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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Reconstruct the MeridianAcornWidgetFlow 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":"MeridianBeaconStoreCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Center the MeridianLedgerGateStore modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"Exporter: The API work is done; what remains for MeridianKiteSchedulerStore is the visible interaction layer across loading, offline, empty, and success cases. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside MeridianKiteSchedulerStore\n- do not introduce another runtime dependency\n\nThe relevant code crosses geospatial, Deno, iPadOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for MeridianAtlasSearchCoordinator:\n- primary outcome: change MeridianAtlasSearchCoordinator's known staging timeout from 15 to 30 seconds\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/meridian/internal/auth/refresh.go\n- platform constraint: Tokio\n- known complication: lost focus when the drawer animation finishes\n\nBoth results are required, but they should remain independently reviewable. Do not introduce another runtime dependency; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Scheduler: Ticket OPS-53114: retire the legacy replay path for MeridianAtlasSearchFlow\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 MeridianAtlasSearchFlow 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":"MeridianNimbusFormCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Two asks around MeridianPineMetricsCoordinator: (1) lay out a staged migration for MeridianPineMetricsCoordinator; (2) also add the visible loading and offline states. Do not introduce another runtime dependency, and leave a clear boundary between the resulting artifacts or edits.","purpose":"planning","secondary":"frontendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"MeridianWrenExportCoordinator: restructure, then document","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Clarify MeridianPineMetricsService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"MeridianMoonlitSDKCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"projects/meridian/ui/settings/PrivacyPane.tsx の MeridianGarnetModalService で、SQLite の flow に断続的な問題が起きています。 consumer 向けに contract、error、retry、コピー可能な例を含む文書を書き、handler は変更しないでください。\n\n制約:\n- SQLite を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は MeridianGarnetModalService のみ","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"ja"}
{"prompt":"Dashboard: The minimum supported SQLite version in projects/meridian/lib/codec/frame.cc is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Translate the MeridianSlateEditorStore setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Worker: The data is already available in projects/meridian/infra/modules/edge/main.tf; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"# projects/meridian/services/ledger/replay.go\n[worker.meridiancedarpolicyflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.meridiancedarpolicyflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.meridiancedarpolicyflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.MeridianCedarPolicyFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-53129\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/meridian/services/ledger/replay.go and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"pasted-context","lang":"en"}
{"prompt":"Animate the MeridianFrostPanelService drawer","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"# CI job 53112: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: WebGPU\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] MeridianSummitProxyFlowIntegration.replays_after_timeout ... ok\n[test] MeridianSummitProxyFlowIntegration.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\nReconstruct the MeridianSummitProxyFlow 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":"Before touching projects/meridian/src/sync/reconcile.ts, 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.9,"slice":"core","lang":"en"}
{"prompt":"Could MeridianMicaProfileStore show the active SQLite sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"I inherited MeridianSummitProxyService and need a careful read of projects/meridian/src/sync/reconcile.ts before I can sign off on the next release. 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- do not introduce another runtime dependency\n- stay compatible with the existing WebGPU deployment\n- keep the work scoped to MeridianSummitProxyService and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"MeridianCinderAuthCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Where did MeridianFernSnapshotService's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"MeridianTideWorkerCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Simulator: # projects/meridian/Sources/CLI/Commands/Doctor.swift\n[worker.meridianechoregistrycoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.meridianechoregistrycoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.meridianechoregistrycoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.MeridianEchoRegistryCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-53156\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/meridian/Sources/CLI/Commands/Doctor.swift and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Runbook: # projects/meridian/cmd/exporter/main.py\n[worker.meridianharborindexflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.meridianharborindexflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.meridianharborindexflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.MeridianHarborIndexFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-53131\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/meridian/cmd/exporter/main.py. 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":"MeridianCoralUploadCoordinator: correct, then assess","purpose":"backendImpl","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Trace: projects/meridian/ml/pipeline/features.py の MeridianBirchMigratorFlow で、NATS JetStream の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- NATS JetStream を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は MeridianBirchMigratorFlow のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"ja"}
{"prompt":"Read projects/meridian/crates/index/src/segment.rs and tell me whether MeridianPrismCacheStore 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":"MeridianCraneWorkspaceCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket: projects/meridian/config/staging.toml 里的 MeridianCraneWorkspaceService 最近在 PostgreSQL 17 流程中出现间歇性问题。 请拆分职责并去掉重复，同时保持 API、wire value、顺序和可观察行为不变。\n\n约束：\n- 继续使用 PostgreSQL 17\n- 保持兼容性和取消语义\n- 改动只限于 MeridianCraneWorkspaceService","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Check MeridianWrenExportStore's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/meridian/lib/codec/frame.cc b/projects/meridian/lib/codec/frame.cc\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/lib/codec/frame.cc\n+++ b/projects/meridian/lib/codec/frame.cc\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 MeridianMicaProfileFlow'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":"Incident timeline — INC-53127\n\n08:02 deploy MeridianJuniperCLIFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the artifact into a reversible MeridianJuniperCLIFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/meridian/Sources/CLI/Commands/Doctor.swift b/projects/meridian/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/meridian/Sources/CLI/Commands/Doctor.swift\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 MeridianAmberFilterFlow 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":"Compare the old and new MeridianNimbusFormStore 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":"Profiler: // projects/meridian/services/ledger/replay.go\nfinal class MeridianCinderAuthFlowCoordinator {\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 MeridianCinderAuthFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-53141\n\n08:02 deploy MeridianSableParserFlow 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 MeridianSableParserFlow 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":"Em projects/meridian/packages/api/openapi.yaml, o MeridianCraneWorkspaceStore tem um problema intermitente no fluxo de PostgreSQL 17. A causa já é conhecida: mude apenas o timeout de staging de 15 para 30 segundos e ajuste a assertion.\n\nRestrições:\n- continuar com PostgreSQL 17\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao MeridianCraneWorkspaceStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"pt"}
{"prompt":"SDK consumers are ready for durable continuation tokens, so the remaining work lives in MeridianSummitProxyStore's API, storage, and worker layers. Add signed cursor parsing, bounded pagination, key rotation, tenant checks, and a resumable background path with metrics for lag, retries, and terminal failures.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside MeridianSummitProxyStore\n- do not introduce another runtime dependency\n\nThe relevant code crosses geospatial, Deno, iPadOS. Prefer evidence from the repository and make any assumption explicit.\n\nThe contract notes are context; the requested outcome is the working server path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"En projects/meridian/ui/settings/PrivacyPane.tsx, MeridianBasilRunnerService tiene un problema intermitente en el flujo de SQLite. La causa ya está clara: cambia solo el timeout de staging de 15 a 30 segundos y ajusta su assertion.\n\nRestricciones:\n- seguir con SQLite\n- conservar compatibilidad y cancelación\n- limitar el cambio a MeridianBasilRunnerService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"es"}
{"prompt":"Wire a MeridianKiteSchedulerFlow background task in projects/meridian/services/ledger/replay.go that expires abandoned sessions, records an OpenTelemetry span, and yields cleanly when shutdown begins.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"MeridianSpruceDaemonFlow occasionally exhibits an accessibility label that reads the internal enum, but only after a reconnect. Follow the data and cancellation paths in projects/meridian/db/migrations/20260730_events.sql and identify the cause before changing anything.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-53154: retire the legacy replay path for MeridianEmberRelayCoordinator\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 MeridianEmberRelayCoordinator 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":"Two deliverables are holding up MeridianMosaicGridCoordinator. First, assess ownership and failure handling in projects/meridian/ui/settings/PrivacyPane.tsx. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/meridian/ui/settings/PrivacyPane.tsx, which follows SQLite conventions and currently suffers from a flaky snapshot caused by locale-dependent sorting. Do not introduce another runtime dependency.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Pin MeridianIrisBatchService's PostgreSQL dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating duplicate retries after a network handoff in MeridianEchoRegistryStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Any races in MeridianLedgerGateService?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Console: // projects/meridian/packages/api/openapi.yaml\nfinal class MeridianNimbusFormFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Consolidate MeridianNimbusFormFlow'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":"The behavior of MeridianBirchMigratorService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/meridian/ml/pipeline/features.py. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current NATS JetStream operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"The MeridianCinderAuthService surface in projects/meridian/services/ledger/replay.go is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"For MeridianSlateEditorCoordinator, lay out a staged migration for MeridianSlateEditorCoordinator; once that is complete, consolidate the duplicated normalization paths without changing behavior. Work from projects/meridian/infra/modules/edge/main.tf, stay with Tokio, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Workspace: Incident timeline — INC-53137\n\n08:02 deploy MeridianOpalRouterFlow 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\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Capture the MeridianOpalRouterFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"A flaky failure around MeridianSpruceDaemonService survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. Trace task lifetime, cursor advancement, and durable acknowledgment across reconnects; produce a defensible root cause and the smallest experiment that would falsify it.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside MeridianSpruceDaemonService\n- do not introduce another runtime dependency\n\nThe relevant code crosses geospatial, Deno, iPadOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"For MeridianJuniperCLICoordinator, produce a consumer guide for MeridianJuniperCLICoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/meridian/app/src/main/SyncWorker.kt, stay with WebGPU, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Por que MeridianJuniperCLIService trava?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"pt"}
{"prompt":"Repository: # projects/meridian/config/staging.toml\n[worker.meridianirisbatchflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.meridianirisbatchflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.meridianirisbatchflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.MeridianIrisBatchFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-53115\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nAlign MeridianIrisBatchFlow's staging timeout with the shown production value and refresh only the focused config test; nothing else in the paste should move.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"PM is preparing the MeridianMapleQueueService rollout and needs prose that works for both application developers and the operators who will carry the pager. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside MeridianMapleQueueService\n- do not introduce another runtime dependency\n\nThe relevant code crosses geospatial, Deno, iPadOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"Pipeline: Ticket OPS-53120: retire the legacy replay path for MeridianWrenExportFlow\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 MeridianWrenExportFlow 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":"Three teams extended MeridianDriftConsoleService independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current WebGPU operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS 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":"Gateway: diff --git a/projects/meridian/db/migrations/20260730_events.sql b/projects/meridian/db/migrations/20260730_events.sql\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/db/migrations/20260730_events.sql\n+++ b/projects/meridian/db/migrations/20260730_events.sql\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 MeridianQuartzPlayerFlow 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":"Renderer: The name pendingAck means two different things across MeridianDeltaCanvasStore's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"MeridianLedgerGateCoordinator needs a paired pass: separate MeridianLedgerGateCoordinator's policy from transport without behavior changes, plus capture the contract and rollback note for consumers. Use projects/meridian/Sources/CLI/Commands/Doctor.swift as the source of truth, preserve the NATS JetStream contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Indexer: Incident timeline — INC-53123\n\n08:02 deploy MeridianFrostPanelFlow 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 MeridianFrostPanelFlow 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":"UI ticket DES-53139: finish the compact MeridianOspreyJobFlow filter experience\n\nRoute: /catalog/search\nSource: projects/meridian/web/components/FilterDrawer.vue\nFramework: Tokio\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nUse the UI evidence to complete MeridianOspreyJobFlow'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":"Apparently: diff --git a/projects/meridian/crates/index/src/segment.rs b/projects/meridian/crates/index/src/segment.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/crates/index/src/segment.rs\n+++ b/projects/meridian/crates/index/src/segment.rs\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 MeridianVelaDrawerFlow 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":"Lately: The public surface of MeridianIrisBatchStore is frozen, but its internal ownership in projects/meridian/packages/api/openapi.yaml is difficult to test and even harder to change safely. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside MeridianIrisBatchStore\n- do not introduce another runtime dependency\n\nThe relevant code crosses geospatial, Deno, iPadOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Oddly: For MeridianAsterWebhookCoordinator, lay out a staged migration for MeridianAsterWebhookCoordinator; once that is complete, consolidate the duplicated normalization paths without changing behavior. Work from projects/meridian/ui/settings/PrivacyPane.tsx, stay with SQLite, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Add a bounded MeridianRavenSessionService 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":"Does MeridianLumenChartFlow enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"MeridianCloudReconcilerService 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":"Responsive layout for MeridianFernSnapshotStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Currently: Incident timeline — INC-53153\n\n08:02 deploy MeridianBasilRunnerCoordinator 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\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Turn the material above into a concise MeridianBasilRunnerCoordinator 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":"Two asks around MeridianHarborIndexCoordinator: (1) finish MeridianHarborIndexCoordinator's responsive empty and retry states; (2) correct the known stale timeout beside it. Do not introduce another runtime dependency, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Today: The MeridianBasilRunnerFlow surface in projects/meridian/ui/settings/PrivacyPane.tsx is stable now; turn its edge cases into API documentation with one successful example and one cancellation example. The deliverable is prose for consumers; do not alter the handler.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"projects/meridian/services/ledger/replay.go has grown through several launches, and MeridianKiteSchedulerService now mixes policy, transport, persistence, and metrics in one place. Separate those responsibilities into focused units, remove the duplicated normalization branches, and keep public types, wire values, log fields, timing, and test-observable behavior exactly the same.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing Tokio deployment\n- keep the work scoped to MeridianKiteSchedulerService and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"MeridianEmberRelayService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Bring the drawer and detail pane to production polish with fluid sizing, honest skeletons, focus restoration, accessible announcements, and touch targets that survive large text.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current Tokio operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"A previously stable test around MeridianTideWorkerStore now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Context: Incident timeline — INC-53113\n\n08:02 deploy MeridianMosaicGridFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Map a safe route from the current MeridianMosaicGridFlow 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":"Background: The behavior of MeridianOrbitSyncStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/meridian/apps/console/routes/usage.svelte. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current WebGPU operational envelope\n\nSeveral teams work in this geospatial, Deno, iPadOS monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe server contract is the subject, but the requested output is documentation rather than handler code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Ticket OPS-53152: retire the legacy replay path for MeridianSpruceDaemonCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCapture the MeridianSpruceDaemonCoordinator 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":"MeridianPrismCacheCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"2026-07-30T08:14:11.409Z level=info service=meridiandriftconsolecoordinator pod=meridiandriftconsolecoordinator-7cf8 request_id=53157 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=meridiandriftconsolecoordinator request_id=53157 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=meridiandriftconsolecoordinator request_id=53157 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=meridiandriftconsolecoordinator request_id=53157 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=meridiandriftconsolecoordinator request_id=53157 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=meridiandriftconsolecoordinator request_id=53157 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=meridiandriftconsolecoordinator request_id=53157 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=meridiandriftconsolecoordinator request_id=53157 msg=\"batch acknowledged\" rows=250\n\nDeployment is Kubernetes 1.34 with four replicas. The warning begins after a consumer rebalance and stops after the pod is restarted. Queue depth remains flat, CPU is 28%, and the readiness probe never fails.\n\nReconstruct the MeridianDriftConsoleCoordinator 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":"MeridianSummitProxyCoordinator is blocking the next release because an empty state that flashes before cached data arrives. I need two concrete outcomes from a single pass: change MeridianSummitProxyCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing WebGPU conventions in projects/meridian/db/migrations/20260730_events.sql; do not introduce another runtime dependency. 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":"MeridianGarnetModalCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Move MeridianDriftConsoleStore's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Read projects/meridian/lib/codec/frame.cc and tell me whether MeridianMicaProfileService can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Question: Ticket OPS-53126: retire the legacy replay path for MeridianLedgerGateFlow\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 MeridianLedgerGateFlow 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":"MeridianOpalRouterCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Match MeridianQuartzPlayerService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Queue MeridianHarborIndexService's expired sessions","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"MeridianAcornWidgetCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Observation: Ticket OPS-53138: retire the legacy replay path for MeridianNovaPickerFlow\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 MeridianNovaPickerFlow 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":"Fresh release brief for MeridianMarbleTokenCoordinator:\n- primary outcome: assess ownership and failure handling in projects/meridian/ml/pipeline/features.py\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/meridian/ml/pipeline/features.py\n- platform constraint: NATS JetStream\n- known complication: out-of-order events after consumer rebalancing\n\nBoth results are required, but they should remain independently reviewable. Do not introduce another runtime dependency; 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":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Document MeridianAcornWidgetStore's cancellation rules","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/meridian/Sources/App/SessionStore.swift, 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":"MeridianBirchMigratorStore'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.2,"slice":"core","lang":"en"}
{"prompt":"MeridianCloudReconcilerCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Enforce MeridianSlateEditorService's idempotency key","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"MeridianOrbitSyncCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"One contained cleanup in projects/meridian/config/staging.toml: remove the obsolete MeridianWillowCodecStore import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Draft MeridianRainfallDBStore's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"MeridianFrostPanelCoordinator: restructure, then document","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/meridian/engine/render/atlas.cpp b/projects/meridian/engine/render/atlas.cpp\nindex 62d71aa..90f3c1e 100644\n--- a/projects/meridian/engine/render/atlas.cpp\n+++ b/projects/meridian/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\nSplit MeridianMapleQueueCoordinator 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":"What is the safest way to split projects/meridian/cmd/exporter/main.py into independently owned modules while MeridianSableParserStore's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Two deliverables are holding up MeridianVelaDrawerCoordinator. First, lay out a staged migration for MeridianVelaDrawerCoordinator. In the same workstream, also add the visible loading and offline states. The relevant starting point is projects/meridian/pkg/cache/lease.rs, which follows PostgreSQL 17 conventions and currently suffers from a deadlock that appears only during shutdown. Do not introduce another runtime dependency.\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":"planning","secondary":"frontendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Store MeridianCopperBridgeStore's delivery receipts","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Assess the MeridianAsterWebhookService diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-53142: retire the legacy replay path for MeridianDeltaCanvasFlow\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\nFrom this evidence, draft consumer-facing migration guidance for MeridianDeltaCanvasFlow, 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":"Could MeridianMoonlitSDKService show the active Tokio sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"MeridianQuartzPlayerCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Give MeridianCedarPolicyService a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-53111\n\n08:02 deploy MeridianMarbleTokenFlow 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 MeridianMarbleTokenFlow 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":"Is MeridianWrenExportService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-53151\n\n08:02 deploy MeridianBirchMigratorCoordinator 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 MeridianBirchMigratorCoordinator, 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":"thread 'tokio-runtime-worker' panicked at projects/meridian/crates/index/src/segment.rs: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: meridianrainfalldbflow::scheduler::LeaseTask::flush\n at ./projects/meridian/crates/index/src/segment.rs:217:18\n 4: meridianrainfalldbflow::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 MeridianRainfallDBFlow 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":"Where did MeridianFrostPanelStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'MeridianBeaconStoreFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[MeridianBeaconStoreFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/meridian/engine/render/atlas.cpp:144: error: -[MeridianBeaconStoreFlowTests 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 '-[MeridianBeaconStoreFlowTests 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 MeridianBeaconStoreFlow'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":"En projects/meridian/ml/pipeline/features.py, MeridianMarbleTokenStore tiene un problema intermitente en el flujo de NATS JetStream. La causa ya está clara: cambia solo el timeout de staging de 15 a 30 segundos y ajusta su assertion.\n\nRestricciones:\n- seguir con NATS JetStream\n- conservar compatibilidad y cancelación\n- limitar el cambio a MeridianMarbleTokenStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"es"}
{"prompt":"Before we approve MeridianNovaPickerService, assess whether an accessibility label that reads the internal enum is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"For MeridianRainfallDBCoordinator, lay out a staged migration for MeridianRainfallDBCoordinator; once that is complete, consolidate the duplicated normalization paths without changing behavior. Work from projects/meridian/pkg/cache/lease.rs, stay with PostgreSQL 17, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_53135'\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_53135'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDeliver the MeridianCraneWorkspaceFlow server-side capability implied above: durable cursors, tenant authorization, idempotent retries, bounded work, telemetry, and focused integration coverage.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Documente le contrat MeridianJuniperCLIStore","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"MeridianFlintTimelineCoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"// projects/meridian/ui/settings/PrivacyPane.tsx\nfinal class MeridianGarnetModalFlowCoordinator {\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 MeridianGarnetModalFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Map MeridianQuartzPlayerStore's ownership split","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Warum hängt MeridianCoralUploadStore?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"Our support and SDK teams keep answering the same questions about MeridianVelaDrawerStore, but the current prose in projects/meridian/pkg/cache/lease.rs only describes the happy path. 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- do not introduce another runtime dependency\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to MeridianVelaDrawerStore and its direct tests\n\nThis repository spans geospatial, Deno, iPadOS; use its existing conventions rather than importing a new abstraction.\n\nThe server contract is the subject, but the requested output is documentation rather than handler code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Compare MeridianAsterWebhookStore's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Remove MeridianHarborIndexStore's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"MeridianOspreyJobCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"SDK consumers are ready for durable continuation tokens, so the remaining work lives in MeridianWillowCodecService's API, storage, and worker layers. Add signed cursor parsing, bounded pagination, key rotation, tenant checks, and a resumable background path with metrics for lag, retries, and terminal failures.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside MeridianWillowCodecService\n- do not introduce another runtime dependency\n\nThe relevant code crosses geospatial, Deno, iPadOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"In projects/meridian/cmd/exporter/main.py hat MeridianMarbleTokenService ein sporadisches Problem im NATS JetStream-Ablauf. Trenne Verantwortlichkeiten und entferne Duplikate, ohne API, Wire-Werte, Reihenfolge oder sichtbares Verhalten zu ändern.\n\nRandbedingungen:\n- NATS JetStream weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf MeridianMarbleTokenService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um MeridianMarbleTokenService mit NATS JetStream kompatibel.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"MeridianOspreyJobService'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":"MeridianCopperBridgeService leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"// projects/meridian/config/staging.toml\nfinal class MeridianWillowCodecCoordinatorCoordinator {\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 MeridianWillowCodecCoordinator; 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":"On compact widths, MeridianTideWorkerService'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.4,"slice":"core","lang":"en"}
{"prompt":"Constraint: // projects/meridian/web/components/FilterDrawer.vue\nfinal class MeridianCoralUploadFlowCoordinator {\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 MeridianCoralUploadFlow; 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"}