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/curation-review-v1.json
+60 -60
View File
@@ -1,12 +1,66 @@
{
"datasetVersion": "purpose-dataset-sol-high-v2",
"humanLabelAndDifficultyReview": {
"decision": "Every supervised target was regenerated with gpt-5.6-sol at high reasoning effort.",
"decisionBasis": "The dataset owner invalidated the original labels and required a complete Sol-high relabel.",
"decisionDate": "2026-08-02",
"generatedArtifact": "ml/purpose-classifier/.artifacts/human-review-v1.csv",
"populationRecords": 12193,
"reviewFields": [
"purpose",
"secondary",
"difficulty",
"slice",
"review status",
"notes"
],
"sampleFraction": 0.1,
"sampleRecords": 1219,
"seed": 10558743,
"status": "superseded-by-sol-high-relabel",
"strata": [
"purpose",
"slice",
"primary language"
]
},
"schemaVersion": 1,
"datasetVersion": "purpose-dataset-v1",
"semanticDuplicateReview": {
"auditVersion": "purpose-semantic-audit-v1",
"decision": "The prior semantic decisions were tied to the invalidated label population; the reset uses deterministic lexical curation only.",
"excluded": [
{
"droppedPromptHash": "7348d764d602cfff72dd2b1d369ad0375a96ea52b38174aa0bd6168a548bcc2f",
"matchedPromptHash": "3ad9cfbb664504f0e7ae84b905520937e7812d4e879fa706415782341f2cd400",
"similarity": 0.984897
},
{
"droppedPromptHash": "a0c6e7984e92adc11ea6855c39688d733bf7665f5f965939325b15f3ba39e937",
"matchedPromptHash": "17f79a890a323c08770193a94b100dadaa00116405bdb7d14c1b89abc3c3066a",
"similarity": 0.980998
},
{
"droppedPromptHash": "bfd7791069fd04c13797f39ba99224ad68ca2deebbc912f08b10815954a7d223",
"matchedPromptHash": "dc48031efb18f25a56a3beddcdd814f26473b23cd496482ce1884ae6f697417a",
"similarity": 0.973329
}
],
"excludedCandidates": 3,
"retained": [
{
"leftPromptHash": "70944e70e0062e947476f73b704ec01ecee19420d06fd174c58a41c04e8112f6",
"rightPromptHash": "cb3e63992cbf5830a222933dc7b44be39933baedcb46e335be02e3c379685517",
"similarity": 0.970376
}
],
"retainedCandidates": 1,
"reviewedCandidates": 4,
"status": "superseded-by-sol-high-relabel"
},
"wordTrigramExclusionReview": {
"status": "complete",
"reviewedRecords": 18,
"confirmedTemplateDuplicates": 18,
"rejectedExclusions": 0,
"decision": "All 18 pairs preserve the same task, requested outcome, and purpose label; differences are generated identifiers, ticket numbers, cosmetic context prefixes, or difficulty/slice metadata. Keep the earliest member and exclude the later template copy.",
"rejectedExclusions": 0,
"reviewedDroppedPromptHashes": [
"f29de1d646055017f80346055bb3ac1468c49af7ab0c6249f45f19cf386f9fa7",
"dabbcd0a19d2918199b5d0d35fac49fd5413cb17a5164252b789114fc68ec43b",
@@ -26,62 +80,8 @@
"fdc04376376dbffcaf9928e9edcef29376203640b49c200c2c117f78891125a1",
"432e67ead52d6cd57e4a5034cd8bcde14bd2da13f88cb5532c42fd8fbd8daf05",
"24f3759ff4a3fb9fc77bed4c8525f30f9af2479a6cffbb0c4842043f99a7d8f1"
]
},
"semanticDuplicateReview": {
"status": "complete",
"auditVersion": "purpose-semantic-audit-v1",
"reviewedCandidates": 4,
"excludedCandidates": 3,
"retainedCandidates": 1,
"decision": "Exclude three same-purpose generated template copies. One pair ('make the screen nicer' / 'Make this screen nicer') remains because it is a deliberate vague-language variant, lives entirely in validation, and does not contaminate the frozen evaluation boundary.",
"excluded": [
{
"droppedPromptHash": "7348d764d602cfff72dd2b1d369ad0375a96ea52b38174aa0bd6168a548bcc2f",
"matchedPromptHash": "3ad9cfbb664504f0e7ae84b905520937e7812d4e879fa706415782341f2cd400",
"similarity": 0.984897
},
{
"droppedPromptHash": "a0c6e7984e92adc11ea6855c39688d733bf7665f5f965939325b15f3ba39e937",
"matchedPromptHash": "17f79a890a323c08770193a94b100dadaa00116405bdb7d14c1b89abc3c3066a",
"similarity": 0.980998
},
{
"droppedPromptHash": "bfd7791069fd04c13797f39ba99224ad68ca2deebbc912f08b10815954a7d223",
"matchedPromptHash": "dc48031efb18f25a56a3beddcdd814f26473b23cd496482ce1884ae6f697417a",
"similarity": 0.973329
}
],
"retained": [
{
"leftPromptHash": "70944e70e0062e947476f73b704ec01ecee19420d06fd174c58a41c04e8112f6",
"rightPromptHash": "cb3e63992cbf5830a222933dc7b44be39933baedcb46e335be02e3c379685517",
"similarity": 0.970376
}
]
},
"humanLabelAndDifficultyReview": {
"status": "accepted-as-generated",
"populationRecords": 12193,
"sampleFraction": 0.1,
"sampleRecords": 1219,
"seed": 10558743,
"strata": [
"purpose",
"slice",
"primary language"
],
"reviewFields": [
"purpose",
"secondary",
"difficulty",
"slice",
"review status",
"notes"
],
"generatedArtifact": "ml/purpose-classifier/.artifacts/human-review-v1.csv",
"decisionDate": "2026-07-31",
"decisionBasis": "The dataset owner explicitly directed the project to assume the generated labels, secondary purposes, difficulties, and slices are correct and validated without completing the row-by-row sample.",
"decision": "Accept the curated generated population as-is. No relabel or reject decisions are inferred, and the blank CSV remains an optional future audit artifact rather than a rollout blocker."
"reviewedRecords": 18,
"status": "complete"
}
}
data/dataset-v1-manifest.json
+76 -79
View File
@@ -1,21 +1,18 @@
{
"curation": {
"excludedDuplicates": {
"near": 18,
"semantic-reviewed": 3
"near": 18
},
"inputRecords": 12214,
"inputRecords": 12007,
"nearDuplicateMethod": "word-trigram Jaccard after SimHash LSH candidate search",
"nearDuplicateThreshold": 0.92,
"retainedRecords": 12193,
"reviewPath": "ml/purpose-classifier/data/curation-review-v1.json",
"reviewSha256": "1721ab77a0f723a4b03f42b14850b5c351ead2cd8fa72bb2d1fe3f0d2bb568da",
"retainedRecords": 11989,
"vagueEvalPolicy": "validation/test only"
},
"datasetVersion": "purpose-dataset-v1",
"datasetVersion": "purpose-dataset-sol-high-v2",
"frozenEval": {
"classifiableShippedFixtureRecords": 87,
"excludedGeneralFixtureRecords": 5,
"classifiableShippedFixtureRecords": 89,
"excludedGeneralFixtureRecords": 3,
"hardSliceDefinition": [
"boundary",
"mixed",
@@ -24,9 +21,9 @@
],
"shippedFixtureRecords": 92,
"shippedFixturesPath": "Tests/NucleicCoreTests/Fixtures/purpose-prompts.json",
"shippedFixturesSha256": "6c8f0eedce35f9da7a407934009e87737b5e85c7371f6a118982d9fae2ea7aae",
"shippedFixturesSha256": "876068ea26d7109365bcfbd1dc44ba3f1a0400c80dc7fdacf008b3fa07cd92cc",
"syntheticPath": "ml/purpose-classifier/data/frozen-test-v1.jsonl",
"syntheticSha256": "5d34c8ac3d39c5b4e2e739c4c9058093beb6f790a42a1397cedefae6271654ab"
"syntheticSha256": "9997dbaa6d305ea56d8c161e39b925368761ab613a706eb8c2ba55d0e58b1906"
},
"ratios": {
"test": 0.1,
@@ -38,113 +35,113 @@
"sources": [
{
"path": "ml/purpose-classifier/data/purpose-prompts.jsonl",
"records": 9214,
"sha256": "3c7f8b496ef2014794a50433a78e3125c0dd4a03dc2a7773b52ee25587ac48e7"
"records": 9007,
"sha256": "6fbd08df113ca4c6f9da151222772dc3e25e1b9b19c9c2b7df9f572053af2507"
},
{
"path": "ml/purpose-classifier/data/purpose-prompts-round2.jsonl",
"records": 3000,
"sha256": "0a35eac2549e95b31518cd0eee99b83b03761c26a0fb258f427fe04a632699ed"
"sha256": "a3c5bbede5b7db743c9f31756491990b388edd2aa9b41c8b2b9ec95b7115f4aa"
}
],
"splits": {
"test": {
"classifiableFixtureRecords": 87,
"classifiableFixtureRecords": 89,
"distribution": {
"language": {
"de": 7,
"en": 1110,
"es": 9,
"fr": 5,
"ja": 3,
"pt": 4,
"de": 6,
"en": 1084,
"es": 7,
"fr": 7,
"ja": 5,
"pt": 7,
"zh": 3
},
"purpose": {
"backendImpl": 171,
"debugging": 149,
"frontendImpl": 157,
"planning": 132,
"quickFix": 140,
"refactor": 136,
"review": 127,
"writing": 129
"backendImpl": 140,
"debugging": 168,
"frontendImpl": 159,
"planning": 120,
"quickFix": 136,
"refactor": 149,
"review": 131,
"writing": 116
},
"slice": {
"boundary": 179,
"core": 507,
"mixed": 80,
"pasted-context": 84,
"vague-eval": 291
"boundary": 51,
"core": 635,
"mixed": 87,
"pasted-context": 77,
"vague-eval": 269
}
},
"hardSyntheticRecords": 634,
"logicalRecords": 1228,
"sha256": "5d34c8ac3d39c5b4e2e739c4c9058093beb6f790a42a1397cedefae6271654ab",
"syntheticRecords": 1141
"hardSyntheticRecords": 484,
"logicalRecords": 1208,
"sha256": "9997dbaa6d305ea56d8c161e39b925368761ab613a706eb8c2ba55d0e58b1906",
"syntheticRecords": 1119
},
"train": {
"distribution": {
"language": {
"de": 100,
"en": 9324,
"es": 100,
"fr": 81,
"ja": 77,
"pt": 70,
"zh": 72
"de": 84,
"en": 9257,
"es": 82,
"fr": 64,
"ja": 62,
"pt": 56,
"zh": 57
},
"purpose": {
"backendImpl": 1226,
"debugging": 1245,
"frontendImpl": 1234,
"planning": 1223,
"quickFix": 1230,
"refactor": 1223,
"review": 1230,
"writing": 1213
"backendImpl": 1223,
"debugging": 1355,
"frontendImpl": 1092,
"planning": 1208,
"quickFix": 1184,
"refactor": 1204,
"review": 1203,
"writing": 1193
},
"slice": {
"boundary": 2066,
"core": 5818,
"mixed": 906,
"pasted-context": 1034
"boundary": 605,
"core": 7175,
"mixed": 987,
"pasted-context": 895
}
},
"records": 9824,
"sha256": "40a5064c2a95d4394d71b3edbad7d03dce7d67b2e5ba9ab9320476e35e3a4953"
"records": 9662,
"sha256": "0e16940308dc7557c73b1b804bf7b715c86d263b613201588ec274169ee01e89"
},
"validation": {
"distribution": {
"language": {
"de": 8,
"en": 1178,
"es": 12,
"de": 10,
"en": 1165,
"es": 10,
"fr": 7,
"ja": 8,
"pt": 8,
"ja": 5,
"pt": 4,
"zh": 7
},
"purpose": {
"backendImpl": 183,
"debugging": 157,
"frontendImpl": 168,
"planning": 141,
"quickFix": 151,
"refactor": 149,
"review": 140,
"writing": 139
"backendImpl": 152,
"debugging": 182,
"frontendImpl": 174,
"planning": 128,
"quickFix": 140,
"refactor": 163,
"review": 143,
"writing": 126
},
"slice": {
"boundary": 195,
"core": 541,
"mixed": 83,
"pasted-context": 95,
"vague-eval": 314
"boundary": 57,
"core": 677,
"mixed": 95,
"pasted-context": 88,
"vague-eval": 291
}
},
"records": 1228,
"sha256": "3d0a3730931db360dd8346cf12d03901ac139acf5be1d9e84975ac591186c588"
"records": 1208,
"sha256": "301cd3d1c69e1bb92b811e857093ad12fb8c5c11bb402ee2993403d5e4467969"
}
}
}
data/frozen-test-v1.jsonl
+985 -1007
View File
File diff suppressed because it is too large Load Diff
data/generation-manifest.json
+26 -9
View File
@@ -1,10 +1,9 @@
{
"schemaVersion": 1,
"dataset": "purpose-classifier-source-v1",
"canonicalFiles": [
"purpose-prompts.jsonl",
"purpose-prompts-round2.jsonl"
],
"dataset": "purpose-classifier-source-v1",
"derivedBatchFiles": [
"round2-01.jsonl",
"round2-02.jsonl",
@@ -24,34 +23,52 @@
],
"generations": [
{
"date": "2026-07-29",
"file": "purpose-prompts.jsonl",
"model": "mixed frontier-model runs (legacy sol/opus aliases; exact model IDs were not retained)",
"date": "2026-07-29",
"notes": "The canonical aggregate was curated from the original per-model batches. Three exact overlaps with the shipped eval fixture were removed on 2026-07-30.",
"prompt": "../datagen-prompt.md",
"topics": [
"web and mobile",
"backend and data",
"infrastructure and systems",
"developer tooling"
],
"notes": "The canonical aggregate was curated from the original per-model batches. Three exact overlaps with the shipped eval fixture were removed on 2026-07-30."
]
},
{
"date": "2026-07-30",
"file": "purpose-prompts-round2.jsonl",
"model": "Nucleic frontier-model generator (exact underlying model ID was not retained)",
"date": "2026-07-30",
"notes": "Corrective generation that counterbalances round-one label, slice, length, opener, and language drift.",
"prompt": "../datagen-prompt-2.md",
"topics": [
"boundary confusion pairs",
"pasted context",
"mixed intent",
"non-English developer prompts"
],
"notes": "Corrective generation that counterbalances round-one label, slice, length, opener, and language drift."
]
}
],
"labeling": {
"date": "2026-08-02",
"files": {
"purpose-prompts-round2.jsonl": {
"records": 3000,
"sha256": "a3c5bbede5b7db743c9f31756491990b388edd2aa9b41c8b2b9ec95b7115f4aa"
},
"purpose-prompts.jsonl": {
"records": 9007,
"sha256": "6fbd08df113ca4c6f9da151222772dc3e25e1b9b19c9c2b7df9f572053af2507"
}
},
"model": "gpt-5.6-sol",
"reasoningEffort": "high",
"schemaVersion": 1,
"scope": "all canonical public prompts; rejected junk removed"
},
"limitations": [
"The exact generator model IDs and sampling parameters were not recorded when the source corpora were created.",
"The round2-NN files are retained generation batches and duplicate the round-two canonical aggregate; dataset tooling must read canonicalFiles only."
]
],
"schemaVersion": 1
}
data/purpose-prompts-round2.jsonl
+2950 -2950
View File
File diff suppressed because it is too large Load Diff
data/purpose-prompts.jsonl
+7151 -7358
View File
File diff suppressed because it is too large Load Diff
data/round2-01.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "our on-call runbook for the settlement job is four years stale. rewrite it against how the job actually behaves today — retry semantics, the manual replay command, who to page", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a partner integration is coming that needs us to expose per-line-item tax breakdown, which we don't currently persist — we compute it at invoice time and throw it away. before we start storing it i want to think through retention, whether we backfill, and what it means for the invoice PDFs that were already generated with the old rounding", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "our device provisioning flow is undocumented and also slightly wrong — the cert rotation step happens after first telemetry, which nobody intended. i need the sequence written up for the field team, and the ordering bug sorted out in the firmware handshake", "purpose": "writing", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "a contractor delivered the disputes module last month and it works, but i haven't read a line of it and we're about to depend on it heavily. go through `services/disputes/` and tell me what you'd flag: correctness, error handling, anything that will hurt at volume, and anything that reads like it was written against an older version of our gateway SDK", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "we're about to move order history off postgres onto a partitioned setup and i genuinely don't know the sequencing. constraints: no downtime, 400M rows, reporting queries hit the same tables, and the mobile team ships a release every tuesday so any API change has to be additive for at least two months. want a migration strategy with rollback points before anyone writes code", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "three helpers in utils/money.ts do rounding: `roundMoney`, `toCents`, `safeRound`. two of them disagree on negatives. collapse them into one and update the ~60 call sites", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "webhook delivery worker needs exponential backoff with jitter, capped at 6 hours, max 12 attempts, then dead-letter", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "payout table needs zebra striping", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "drop the currency symbol from the cart subtotal, product asked", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "src/pipeline/transform_orders.py is 1100 lines and every dbt model imports from it. i want it broken into something sane — but first tell me how you'd carve it up and in what order, then do the first slice", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "same three lines of duplicated setup at the top of every one of these tests. worth extracting a fixture?\n\ndef test_charge_declined(db, monkeypatch):\n gw = FakeGateway()\n monkeypatch.setattr(charges, \"gateway\", gw)\n order = make_order(db, total=Decimal(\"25.00\"), currency=\"usd\")\n gw.next_response = DECLINE\n with pytest.raises(ChargeDeclined):\n charges.capture(order)\n\ndef test_charge_partial(db, monkeypatch):\n gw = FakeGateway()\n monkeypatch.setattr(charges, \"gateway\", gw)\n order = make_order(db, total=Decimal(\"25.00\"), currency=\"usd\")\n gw.next_response = PARTIAL\n result = charges.capture(order)\n assert result.captured == Decimal(\"10.00\")\n\ndef test_charge_retries_on_timeout(db, monkeypatch):\n gw = FakeGateway()\n monkeypatch.setattr(charges, \"gateway\", gw)\n order = make_order(db, total=Decimal(\"25.00\"), currency=\"usd\")\n gw.responses = [TIMEOUT, OK]\n assert charges.capture(order).attempts == 2", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "design ticket from figma handoff — build the empty state for the payouts screen:\n\nPayouts • Empty state\nIllustration: 160x160, centered, 32px above the heading. Use the existing `illustration/wallet` asset.\nHeading: \"No payouts yet\" — text-lg, semibold, foreground.\nBody: \"Payouts appear here once your first order settles. This usually takes 2 business days.\" — text-sm, muted-foreground, max-width 420px, centered.\nPrimary button: \"View settlement schedule\" — secondary variant, opens the schedule sheet.\nSpacing: 96px top padding on desktop, 48px on mobile.\nDark mode: illustration swaps to the `-dark` variant; nothing else changes.\nMotion: fade + 8px rise on mount, 180ms ease-out, respects reduced-motion.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "paste of the dedup helper in the ingestion job. two of these live in the repo (one in `ingest/`, one in `backfill/`) and they've drifted. unify them:\n\ndef dedupe(rows, key=lambda r: r[\"id\"]):\n seen = set()\n out = []\n for r in rows:\n k = key(r)\n if k in seen:\n continue\n seen.add(k)\n out.append(r)\n return out\n\n# backfill/util.py version\ndef dedupe_rows(rows, key_field=\"id\", keep=\"last\"):\n index = {}\n for r in rows:\n k = r.get(key_field)\n if keep == \"last\" or k not in index:\n index[k] = r\n return list(index.values())\n\ncallers: ingest/orders.py:88, ingest/refunds.py:41, backfill/orders.py:210, backfill/merchants.py:77, tools/reconcile.py:19", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "can you look over the new webhook signature verification and also write up how partners should implement it on their end", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "o job de conciliação está a demorar 3h e ninguém sabe porquê. antes de mexer, explica-me o que ele faz passo a passo", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "pt"}
{"prompt": "invoice numbering has to be gapless per legal entity, and right now it's a `MAX(id)+1` in the app. i need both the approach and the actual implementation — sequence table vs advisory lock vs something else, then build it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "before we ship split-tender i want a written threat model of the auth-then-void window, and then the guard rails implemented in the charge service", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "settlement docs and the settlement code disagree about when a batch closes. figure out which one is lying, then fix whichever is wrong", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "the k6 run against staging ingest, before and after we turned on batching. is this actually better or am i reading noise?\n\n scenarios: (100.00%) 1 scenario, 400 max VUs, 5m30s max duration\n\n checks.........................: 99.81% ✓ 238914 ✗ 452\n data_received..................: 1.4 GB 4.6 MB/s\n http_req_blocked...............: avg=1.21ms min=1µs med=4µs max=1.02s\n http_req_duration..............: avg=411.02ms min=18.11ms med=298ms max=9.81s\n { expected_response:true }...: avg=402.55ms min=18.11ms med=291ms max=9.81s\n http_req_failed................: 0.18% ✓ 452 ✗ 238914\n http_reqs......................: 239366 798.55/s\n iteration_duration.............: avg=1.24s min=201ms med=1.11s max=11.2s\n vus............................: 400 min=40 max=400\n\n ✗ p(95) < 500ms\n ↳ p(95)=1.42s", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "support keeps forwarding this and i want one canonical doc instead of ten slack answers:\n\n> Hi — we're integrating your payouts API and the docs don't say what happens when a payout fails. Do you retry automatically? Is there a webhook? We saw a payout go from `pending` to `failed` and then back to `pending` two hours later which we did not expect. Also: are `failure_code` values stable enough to switch on, or should we treat them as display-only? Our finance team needs to know whether a `failed` payout can still settle later, because we've already reversed the ledger entry on our side by then.\n\nwrite the page that answers all of that", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "two of these do the same job with different names and one of them silently swallows the error. collapse them:\n\n// packages/gateway/src/http.ts\nexport async function postJSON(url: string, body: unknown, timeoutMs = 30_000) {\n const ctrl = new AbortController()\n const t = setTimeout(() => ctrl.abort(), timeoutMs)\n try {\n const res = await fetch(url, { method: 'POST', body: JSON.stringify(body), signal: ctrl.signal })\n if (!res.ok) throw new GatewayError(res.status, await res.text())\n return await res.json()\n } finally {\n clearTimeout(t)\n }\n}\n\n// packages/gateway/src/legacy/request.ts\nexport async function sendJson(url, payload, opts = {}) {\n try {\n const res = await fetch(url, { method: 'POST', body: JSON.stringify(payload) })\n return await res.json()\n } catch (e) {\n return null\n }\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "someone drafted this migration for the split-tender work. would this lock the table in prod?\n\nBEGIN;\n\nALTER TABLE orders ADD COLUMN tender_count smallint NOT NULL DEFAULT 1;\n\nALTER TABLE payments\n ADD COLUMN instrument_kind text NOT NULL DEFAULT 'card',\n ADD CONSTRAINT payments_instrument_kind_chk\n CHECK (instrument_kind IN ('card','gift_card','store_credit'));\n\nCREATE INDEX idx_payments_order_instrument\n ON payments (order_id, instrument_kind);\n\nUPDATE payments SET instrument_kind = 'gift_card'\n WHERE gateway = 'internal_gc';\n\nALTER TABLE payments ALTER COLUMN instrument_kind DROP DEFAULT;\n\nCOMMIT;\n\npayments is 190M rows, postgres 15, no downtime window", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "there's a `docs/adr/` folder with eleven ADRs and four of them describe systems we deleted. clear out the dead ones, and write a new ADR covering the ledger v2 decision we actually made in march but never recorded", "purpose": "writing", "secondary": "refactor", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "firmware devices on the 4.1 build sometimes report telemetry timestamps a year in the future and our ingest happily accepts them, poisoning the warehouse. find out where the clock goes wrong on the device side, and add the ingest-side guard so bad timestamps never land again", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "merchant dashboard imports the design system in three different ways depending on when the file was written: barrel imports, deep paths, and a couple of copy-pasted components that were never migrated. normalise all of it, delete the copies, same pixels on screen afterwards", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "dedupe the two CSV writers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "we inherited a rust firmware crate from an acquisition and the interrupt handling in `src/rt/isr.rs` looks unusual to me — there's a static mut ring buffer touched from both the ISR and the main loop with a bare `unsafe` and no critical section. is that actually sound on a single-core cortex-m, or are we one compiler upgrade away from disaster", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "three of us reviewed the ledger PR and disagreed about whether the compensating-entry approach is sound. settle it — read `internal/ledger/` and tell me who's right", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "webhook signing helper is duplicated between the node SDK and the python SDK and they've drifted on how they canonicalise the payload. get them back in sync, then add the note to both SDK readmes so integrators know which versions changed", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "we're a four-person team and every deploy needs someone to babysit the settlement job afterwards. that's not sustainable for the next quarter when we double order volume. what would you sequence — better alerting first, or making the job idempotent so a bad deploy doesn't need a human? give me the reasoning and a rough order of work, not code", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "payout amount doc, for support", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "checkout blows up for about 1 in 40 carts and this is all sentry gives me:\n\nTypeError: Cannot read properties of undefined (reading 'currency')\n at normalizeLineItem (/srv/checkout/dist/cart/normalize.js:88:31)\n at Array.map (<anonymous>)\n at buildOrderDraft (/srv/checkout/dist/cart/draft.js:42:38)\n at async createOrder (/srv/checkout/dist/orders/create.js:117:20)\n at async /srv/checkout/dist/http/routes/orders.js:29:24\n at async Object.handler (/srv/checkout/node_modules/fastify/lib/handleRequest.js:129:9)\n {\n requestId: 'req_9f2b1c',\n cartId: 'cart_01HQ8V',\n lineItems: 4,\n promoApplied: true,\n userAgent: 'Shopify-Mobile/9.4.1 (iOS 18.2)'\n }\n\nit only ever fires when a promo is on the cart, never on a plain cart. no idea what makes those items different", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "why does the ESP32 reboot roughly 40s after it associates to wifi? nothing in my firmware touches the watchdog", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "toolbar icons are 1px off center in dark mode only", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "npm audit tail from the payments package, tell me which of these actually matter for us and just do the safe upgrades:\n\n# npm audit report\n\naxios 1.6.0 - 1.7.3\nSevere: Server-Side Request Forgery in axios\nfix available via `npm audit fix --force`\nWill install [email protected], which is a breaking change\nnode_modules/axios\n @acme/gateway-sdk 0.4.0 - 0.9.2\n Depends on vulnerable versions of axios\n node_modules/@acme/gateway-sdk\n\ntar-fs 2.0.0 - 2.1.1\nModerate: Link Following in tar-fs\nfix available via `npm audit fix`\nnode_modules/tar-fs\n\n7 vulnerabilities (4 moderate, 3 high)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "continue from where the sync work stopped", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "here's the hunk that landed friday. does it hold up?\n\n@@ -41,17 +41,24 @@ func (s *Settler) Settle(ctx context.Context, batchID string) error {\n-\ttx, err := s.db.BeginTx(ctx, nil)\n+\ttx, err := s.db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})\n \tif err != nil {\n \t\treturn err\n \t}\n-\tdefer tx.Rollback()\n+\tdefer func() { _ = tx.Rollback() }()\n \n \trows, err := tx.QueryContext(ctx, selectPendingSQL, batchID)\n \tif err != nil {\n \t\treturn err\n \t}\n+\tdefer rows.Close()\n \n \tfor rows.Next() {\n \t\tvar p payout\n \t\tif err := rows.Scan(&p.ID, &p.AmountCents, &p.Currency); err != nil {\n \t\t\treturn err\n \t\t}\n-\t\tif err := s.send(ctx, p); err != nil {\n+\t\tgo func(p payout) {\n+\t\t\t_ = s.send(ctx, p)\n+\t\t}(p)\n-\t\t\treturn err\n-\t\t}\n \t}\n \treturn tx.Commit()\n }", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "ticket copy below, turn it into customer-facing release notes for the 4.2 firmware drop. keep it short, they are field techs not engineers:\n\nFW-2201 — Modbus RTU timing\nDevices on long RS-485 runs (>300m) intermittently dropped frames when polled faster than 20Hz. Root cause was the inter-frame delay being computed from the nominal baud rate rather than the measured one. Fixed by sampling the actual bit time at link-up.\n\nFW-2214 — Battery gauge drift\nThe SoC estimate drifted up to 12% after ~40 charge cycles because the coulomb counter was never re-zeroed at full charge. Now re-zeroes when terminal voltage holds above 4.15V for 90 seconds.\n\nFW-2230 — OTA rollback\nA failed OTA could leave slot B marked valid. Bootloader now requires a heartbeat from the new image within 60s before confirming.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "rename `TxnCtx` to `PaymentContext` everywhere, it's in about 30 files", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "pytest output, no clue why this only fails on CI:\n\n=================================== FAILURES ===================================\n_______________ test_settlement_rounds_half_even[eur-2.005] ____________________\n\namounts = ['2.005', '10.115', '0.005']\n\n @pytest.mark.parametrize(\"currency,amount\", CASES)\n def test_settlement_rounds_half_even(currency, amount):\n got = settle(Decimal(amount), currency)\n> assert got == Decimal(\"2.00\")\nE assert Decimal('2.01') == Decimal('2.00')\nE + where Decimal('2.01') = settle(Decimal('2.005'), 'eur')\n\ntests/test_settlement.py:64: AssertionError\n=========================== short test summary info ============================\nFAILED tests/test_settlement.py::test_settlement_rounds_half_even[eur-2.005]\nFAILED tests/test_settlement.py::test_settlement_rounds_half_even[eur-0.005]\n2 failed, 318 passed in 41.22s\n\nlocally all 320 pass. same python version per the container image", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "give the dashboard some love", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "quiero un README para el paquete `acme-payments-sdk`, con ejemplos de uso y la tabla de errores", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "es"}
{"prompt": "epic dropped in my lap this morning, need a shape for it before standup:\n\nPAY-880: Split-tender checkout\nCustomers should be able to pay with up to three instruments on one order (gift card + card + store credit). Partial authorization must be supported; if the second instrument declines we must void the first within 30s or the customer sees a phantom hold. Refunds must unwind in reverse order of capture. Accounting needs one journal entry per instrument, not per order. Mobile and web both in scope; POS is explicitly out of scope for this quarter. Legal wants a written record of authorization order for disputes.\n\nno estimates yet, just want the milestones and where the risk is", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "skeleton loader for the orders table please, matching the card one we already have", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "git log since v3.8 is below, produce the changelog entry. group by user-visible vs internal, drop the noise:\n\n8f21c0a fix(cart): guard against null promo on line items\n1b93de2 chore: bump esbuild 0.21.5 -> 0.23.0\nc0aa774 feat(checkout): remember last used shipping method\n77de110 refactor(orders): extract draft builder\n2e91b45 fix(orders): don't double-count tax on split shipments\naa30f19 test: flaky settlement rounding case\n9c1d004 feat(admin): bulk refund from the order list\n4410bb7 chore(deps): dependabot bump tar-fs\nb77e910 fix(webhooks): retry paypal IPN on 5xx instead of dropping\n30cc219 docs: correct the payout schedule table\ne1f0a52 perf(cart): memoize currency formatter", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "walk me through what `reconcileLedger` actually does before i touch it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "serial console from the gateway board, it wedges after a few hours in the field but never on my desk:\n\n[00:04:12.331] mqtt: connected broker=ssl://ingest.acme.io:8883\n[01:58:03.117] mqtt: publish qos=1 topic=v1/telemetry len=284\n[01:58:03.402] mqtt: puback id=41221\n[02:11:44.980] wifi: rssi=-81 (weak)\n[02:11:47.002] mqtt: keepalive timeout, reconnecting\n[02:11:47.004] net: dhcp renew\n[02:11:52.118] mqtt: connect failed rc=-2\n[02:12:02.118] mqtt: connect failed rc=-2\n[02:12:12.119] mqtt: connect failed rc=-2\n[02:12:12.120] heap: free=3128 largest=1024 min_ever=3128\n[02:12:22.121] mqtt: connect failed rc=-2\n[02:12:22.122] heap: free=2104 largest=768 min_ever=2104\n[02:12:32.123] mqtt: connect failed rc=-2\n[02:12:32.124] heap: free=1080 largest=512 min_ever=1080\n<no further output>", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "nochmal die Frage: warum ruft der Checkout `getShippingRates` zweimal auf, wenn man die Adresse ändert?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "de"}
{"prompt": "do the thing with the invoices", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "ruff is unhappy on the pipeline package, clear these out:\n\npipelines/orders/load.py:12:1: F401 [*] `datetime.timezone` imported but unused\npipelines/orders/load.py:88:5: E722 Do not use bare `except`\npipelines/orders/load.py:141:9: F841 Local variable `rowcount` is assigned to but never used\npipelines/orders/transform.py:23:1: E402 Module level import not at top of file\npipelines/orders/transform.py:210:80: E501 Line too long (118 > 100)\npipelines/orders/transform.py:377:15: B008 Do not perform function call `dict()` in argument defaults\npipelines/common/io.py:5:1: F401 [*] `typing.Optional` imported but unused\npipelines/common/io.py:66:12: SIM108 Use ternary operator instead of `if`-`else`-block\nFound 8 errors (3 fixable with the `--fix` option).", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "our staging environment shares a gateway sandbox account with two other teams, which is why our e2e tests are flaky, and i'm tired of it. options as i see them: our own sandbox account, a recorded-fixtures approach, or a fake gateway we maintain. weigh those up for a team our size and tell me what you'd do", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "a merchant reported that their payout for tuesday arrived split into two payments with different reference numbers, which shouldn't be possible. i've been staring at the batching code for an hour. the batch closes on a size trigger and a time trigger and i think both can fire, but i can't prove it from reading. take a look and explain what's happening", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our checkout conversion dropped 4% on android chrome last week and nothing in the payments code changed. the only thing i can find is that the card element sometimes doesn't get focus on first tap. i don't know whether that's the cause or a red herring, and i don't know how to tell", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "a `/v1/instruments` endpoint is needed: list saved payment instruments for the authenticated merchant's customer, with the default one first, expired cards excluded unless `include_expired=true`, and last-four plus brand only — never the token. keep it consistent with how `/v1/orders` handles auth and pagination", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "finish it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "POST /v1/refunds handler is pasted below — i need the public API reference page for it. request/response schema, every error code, and an idempotency note:\n\[email protected](\"/v1/refunds\", status_code=201)\nasync def create_refund(body: RefundIn, idem: str = Header(alias=\"Idempotency-Key\")):\n order = await orders.get(body.order_id)\n if order is None:\n raise HTTPException(404, \"order_not_found\")\n if order.state not in (\"captured\", \"partially_refunded\"):\n raise HTTPException(409, \"order_not_refundable\")\n if body.amount_cents > order.refundable_cents:\n raise HTTPException(422, \"amount_exceeds_refundable\")\n existing = await idem_store.get(idem)\n if existing:\n return existing\n refund = await gateway.refund(order.charge_id, body.amount_cents, reason=body.reason)\n await idem_store.put(idem, refund, ttl=86400)\n return refund", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "airflow scheduler log tail — the daily orders DAG has been marked success while producing nothing for three days:\n\n[2026-07-27, 02:00:04 UTC] {scheduler_job.py:412} INFO - DAG orders_daily scheduled run 2026-07-26\n[2026-07-27, 02:00:09 UTC] {taskinstance.py:1157} INFO - Executing extract_orders on 2026-07-26T00:00:00+00:00\n[2026-07-27, 02:00:11 UTC] {sql.py:88} INFO - Running: SELECT * FROM orders WHERE updated_at >= '2026-07-26' AND updated_at < '2026-07-27'\n[2026-07-27, 02:00:12 UTC] {sql.py:96} INFO - Fetched 0 rows\n[2026-07-27, 02:00:12 UTC] {taskinstance.py:1372} INFO - Marking task as SUCCESS\n[2026-07-27, 02:00:13 UTC] {taskinstance.py:1157} INFO - Executing load_warehouse on 2026-07-26T00:00:00+00:00\n[2026-07-27, 02:00:14 UTC] {load.py:52} INFO - upserting 0 rows into warehouse.fct_orders\n[2026-07-27, 02:00:14 UTC] {taskinstance.py:1372} INFO - Marking task as SUCCESS\n[2026-07-27, 02:00:15 UTC] {dagrun.py:604} INFO - Marking run <DagRun orders_daily @ 2026-07-26> successful\n\nthe source table definitely has rows for those days", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "explain plan for our slowest reporting query, is the sort the real problem or is it the nested loop:\n\nGroupAggregate (cost=2841002.31..2912441.09 rows=1428215 width=48) (actual time=18422.113..21033.885 rows=1201 loops=1)\n Group Key: m.merchant_id, date_trunc('day', o.captured_at)\n -> Sort (cost=2841002.31..2844572.85 rows=1428215 width=32) (actual time=18421.980..19884.210 rows=4118222 loops=1)\n Sort Key: m.merchant_id, (date_trunc('day', o.captured_at))\n Sort Method: external merge Disk: 214880kB\n -> Nested Loop (cost=0.43..2610411.02 rows=1428215 width=32) (actual time=0.061..14022.771 rows=4118222 loops=1)\n -> Seq Scan on merchants m (cost=0.00..812.44 rows=3244 width=16) (actual time=0.008..1.902 rows=3244 loops=1)\n -> Index Scan using orders_merchant_captured_idx on orders o (cost=0.43..798.11 rows=440 width=24) (actual time=0.004..3.902 rows=1269 loops=3244)\n Index Cond: (merchant_id = m.merchant_id)\nPlanning Time: 0.641 ms\nExecution Time: 21041.223 ms", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "gift card balance shows stale after a partial redemption — i think it's just the cache key missing the version, one-line change if so", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "dependabot opened this and i can't tell if it's safe to merge blind:\n\nBumps `pyarrow` from 14.0.2 to 17.0.0.\n\nRelease notes (17.0.0):\n- ARROW-41567: [Python] Deprecate `pyarrow.parquet.ParquetDataset` legacy behaviour; `use_legacy_dataset` removed\n- ARROW-42011: [C++] Default compression for `write_table` changed from `snappy` to `zstd`\n- ARROW-40199: [Python] `Table.to_pandas` now returns nullable dtypes by default when `types_mapper` is unset\n- ARROW-43121: [C++] Minimum supported glibc raised to 2.28\n\nCommits\n- 9a1b2c3 MINOR: bump version\n- 77aa019 ARROW-43121: raise glibc floor\n- 2b91d40 ARROW-40199: nullable dtypes by default\n\nCompatibility score: 61%", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "browser console on the checkout page, customers report the pay button doing nothing:\n\nrefused to execute inline script because it violates the following Content Security Policy directive: \"script-src 'self' https://js.stripe.com\"\n (index):1\nUncaught (in promise) IntegrationError: We could not retrieve data from the specified Element. Please make sure the Element you are attempting to use is still mounted.\n at Bn (v3:1:19233)\n at e._handleMessage (v3:1:41102)\n at e._handleMessage (v3:1:40011)\npayment-form.tsx:212 Uncaught TypeError: Cannot read properties of null (reading 'confirmPayment')\n at handleSubmit (payment-form.tsx:212:28)\n at HTMLFormElement.callCallback (react-dom.development.js:4164:14)\nGET https://api.acme.io/v1/payment_intents/pi_3Qb 401 (Unauthorized)\n\nhappens on safari only as far as we can tell", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "comparto el hilo de slack de anoche, resúmelo en un post-mortem para el canal #incidents:\n\nmarta: el settlement job lleva 40 min parado\nmarta: los locks en payouts están al rojo\ndani: yo veo la conexión del pooler saturada, 200/200\ndani: creo que alguien lanzó el replay manual sin el flag de batch\nmarta: confirmado, jorge lo lanzó a las 21:14 para el merchant 8812\njorge: perdón, pensaba que el replay ya iba en lotes\ndani: he matado el proceso, los locks se liberaron a las 21:52\nmarta: cola drenada a las 22:06, sin pagos perdidos\ndani: mañana metemos un guard para que replay sin --batch no arranque\nmarta: y hay que documentarlo, nadie sabía que era peligroso", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "es"}
{"prompt": "tax calculation lives in the order service, the cart service and the admin refund flow. i want one owner for it. sketch the target shape and the steps to get there without a big-bang cutover", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "got this in prod, go service, no idea:\n\npanic: send on closed channel\n\ngoroutine 214 [running]:\nacme/settle.(*Batcher).enqueue(0xc0001a4000, {0xc0004b2100, 0x18})\n\t/build/settle/batcher.go:132 +0x9c\nacme/settle.(*Batcher).Add(...)\n\t/build/settle/batcher.go:98\nacme/settle.(*Worker).handle(0xc0000b6060, {0x8f2d40, 0xc0001bc0c0})\n\t/build/settle/worker.go:74 +0x1c5\nacme/settle.(*Worker).Run.func1()\n\t/build/settle/worker.go:41 +0x59\ncreated by acme/settle.(*Worker).Run in goroutine 1\n\t/build/settle/worker.go:39 +0x8d\n\nexit status 2\n\nit survived four weeks in staging without a single one of these", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "terraform for the ingest bucket, below. anything here that would make an auditor unhappy?\n\nresource \"aws_s3_bucket\" \"ingest\" {\n bucket = \"acme-ingest-prod\"\n}\n\nresource \"aws_s3_bucket_public_access_block\" \"ingest\" {\n bucket = aws_s3_bucket.ingest.id\n block_public_acls = true\n ignore_public_acls = true\n block_public_policy = false\n restrict_public_buckets = false\n}\n\nresource \"aws_s3_bucket_policy\" \"ingest\" {\n bucket = aws_s3_bucket.ingest.id\n policy = jsonencode({\n Version = \"2012-10-17\"\n Statement = [{\n Effect = \"Allow\"\n Principal = \"*\"\n Action = [\"s3:GetObject\"]\n Resource = \"${aws_s3_bucket.ingest.arn}/public/*\"\n }]\n })\n}\n\nresource \"aws_s3_bucket_lifecycle_configuration\" \"ingest\" {\n bucket = aws_s3_bucket.ingest.id\n rule {\n id = \"expire-raw\"\n status = \"Enabled\"\n expiration { days = 3650 }\n }\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec below, stand up the endpoint. postgres + sqlc, follow how /v1/orders does it:\n\nGET /v1/settlements\n query: merchant_id (required), from (date), to (date), status (pending|paid|failed), cursor, limit (default 50, max 200)\n auth: merchant-scoped API key; a platform key may pass merchant_id for any merchant it owns\n response: { data: Settlement[], next_cursor: string|null }\n Settlement: { id, merchant_id, amount_cents, currency, status, expected_at, paid_at|null, failure_code|null }\n ordering: expected_at desc, id desc\n errors: 400 invalid_range if to < from, 403 merchant_not_owned, 422 limit_out_of_range\n the cursor must be opaque and must survive new rows being inserted mid-page", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "diff below — write the commit message. we squash, so one subject line plus a body:\n\ndiff --git a/internal/ledger/post.go b/internal/ledger/post.go\n@@ -18,6 +18,7 @@ type Entry struct {\n \tAccount string\n \tAmount int64\n \tCurrency string\n+\tBatchID string\n }\n@@ -55,9 +56,16 @@ func Post(ctx context.Context, db DB, entries []Entry) error {\n-\tfor _, e := range entries {\n-\t\tif _, err := db.Exec(ctx, insertEntry, e.Account, e.Amount, e.Currency); err != nil {\n-\t\t\treturn err\n-\t\t}\n-\t}\n+\tbatch := &pgx.Batch{}\n+\tfor _, e := range entries {\n+\t\tbatch.Queue(insertEntry, e.Account, e.Amount, e.Currency, e.BatchID)\n+\t}\n+\tres := db.SendBatch(ctx, batch)\n+\tdefer res.Close()\n+\tfor range entries {\n+\t\tif _, err := res.Exec(); err != nil {\n+\t\t\treturn fmt.Errorf(\"post entry: %w\", err)\n+\t\t}\n+\t}\n \treturn nil\n }", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "sort out the invoice thing from yesterday", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "docs/webhooks.md still describes the v1 payload shape we killed in march. bring it in line with what we send now, and add the migration note partners keep asking for", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "help", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "summarise what the settlement service does for a new hire, then turn that into the actual service README", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt": "reading through the fraud scoring service for the first time. give me the tour — entry points, what calls what, where the model gets loaded, and anything that looks load-bearing but undocumented", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "loading spinner on the refunds table flashes for 40ms then disappears, looks broken", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "unify the two date formatters and then note it in the changelog", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.35, "slice": "mixed", "lang": "en"}
{"prompt": "dark mode on the invoice preview inverts the PDF thumbnail and it looks terrible", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "needs to be faster", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "docstrings in `pipelines/common/io.py` are wrong about what happens on partial writes — they describe behaviour we removed. correct them to match the code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "我们的 payout 对账逻辑要不要拆成独立服务？先给我一个方案对比，别写代码", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "zh"}
{"prompt": "same thing as last time but for refunds", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "tell me whether the retry logic in `gateway/client.go` can double-charge, and if it can, patch it", "purpose": "review", "secondary": "quickFix", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "stale `TODO(marta): remove after Q1` comments all over the ingest package, it's Q3", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "just make the dashboard usable again", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "jest is red after the money refactor and i can't tell if the test or the code is wrong:\n\n FAIL src/cart/__tests__/totals.test.ts\n ● cart totals › applies percentage promo before shipping\n\n expect(received).toEqual(expected) // deep equality\n\n - Expected - 3\n + Received + 3\n\n Object {\n - \"discountCents\": 450,\n - \"shippingCents\": 599,\n - \"totalCents\": 4649,\n + \"discountCents\": 449,\n + \"shippingCents\": 599,\n + \"totalCents\": 4650,\n \"subtotalCents\": 4500,\n }\n\n at Object.<anonymous> (src/cart/__tests__/totals.test.ts:88:23)\n\nTests: 1 failed, 214 passed, 215 total\nSnapshots: 0 total\nTime: 18.446 s", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "prometheus alert fired overnight and i don't understand the rule, let alone the alert:\n\nALERT SettlementLagHigh\n expr: max by (region) (settlement_batch_age_seconds{env=\"prod\"}) > 900\n for: 10m\n labels: { severity: page, team: payments }\n annotations:\n summary: \"settlement batches lagging in {{ $labels.region }}\"\n\nfiring instances:\n settlement_batch_age_seconds{env=\"prod\",region=\"eu-west-1\",shard=\"3\"} 1841\n settlement_batch_age_seconds{env=\"prod\",region=\"eu-west-1\",shard=\"7\"} 1802\n settlement_batch_age_seconds{env=\"prod\",region=\"us-east-1\",shard=\"1\"} 212\n\nlag cleared on its own at 04:12 without anyone touching it", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "jira ticket, verbatim, and i want the rollout plan not the code:\n\nDATA-417 — Retire the nightly full refresh\nToday `warehouse_refresh` truncates and rebuilds fct_orders, fct_payments and dim_merchant every night (runtime 3h10m, growing ~4%/month). We want incremental models instead. Constraints: finance reconciles against fct_payments at 06:00 UTC and cannot see partial state; the merchant dimension is SCD2 and history must not be rewritten; three downstream Looker models and one ML feature job read these tables. There is no staging warehouse with production volume. Prior attempt in February was rolled back after duplicate rows appeared in fct_payments.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "eslint output after the checkout rewrite, just make it quiet:\n\n/app/src/checkout/PaymentForm.tsx\n 14:8 warning 'useMemo' is defined but never used @typescript-eslint/no-unused-vars\n 88:11 error 'cardToken' is assigned a value but never used @typescript-eslint/no-unused-vars\n 132:5 error React Hook useEffect has a missing dependency: 'merchantId' react-hooks/exhaustive-deps\n 204:7 warning Unexpected console statement no-console\n\n/app/src/checkout/SummaryPanel.tsx\n 9:1 error 'formatMoney' is defined but never used @typescript-eslint/no-unused-vars\n 41:22 error Missing \"key\" prop for element in iterator react/jsx-key\n\n✖ 6 problems (4 errors, 2 warnings)\n 3 errors and 0 warnings potentially fixable with the `--fix` option.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "cargo clippy on the firmware crate, mostly noise but a couple look real:\n\nwarning: this `if` statement can be collapsed\n --> src/modbus/frame.rs:118:5\n |\n118 | / if crc_ok {\n119 | | if len >= MIN_FRAME {\n | |_________^\n = help: for further information visit https://rust-lang.github.io/rust-clippy/\n\nwarning: casting `u32` to `u16` may truncate the value\n --> src/modbus/timing.rs:44:23\n |\n44 | let ticks: u16 = (bit_time_ns / 1000) as u16;\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nwarning: large size difference between variants\n --> src/proto/mod.rs:12:1\n |\n12 | enum Msg { Ping, Telemetry([u8; 512]) }\n\nwarning: `acme-fw` (lib) generated 14 warnings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "ingest handler as it stands, pasted below. i want the same behaviour with the nesting flattened out, it's five levels deep in places:\n\nfunc (h *Handler) Ingest(w http.ResponseWriter, r *http.Request) {\n\tif r.Method == http.MethodPost {\n\t\tif ct := r.Header.Get(\"Content-Type\"); ct == \"application/json\" {\n\t\t\tvar batch Batch\n\t\t\tif err := json.NewDecoder(r.Body).Decode(&batch); err == nil {\n\t\t\t\tif len(batch.Readings) > 0 {\n\t\t\t\t\tif h.limiter.Allow(batch.DeviceID) {\n\t\t\t\t\t\tif err := h.store.Write(r.Context(), batch); err == nil {\n\t\t\t\t\t\t\tw.WriteHeader(202)\n\t\t\t\t\t\t\treturn\n\t\t\t\t\t\t}\n\t\t\t\t\t\thttp.Error(w, \"store\", 500)\n\t\t\t\t\t\treturn\n\t\t\t\t\t}\n\t\t\t\t\thttp.Error(w, \"rate\", 429)\n\t\t\t\t\treturn\n\t\t\t\t}\n\t\t\t}\n\t\t\thttp.Error(w, \"bad json\", 400)\n\t\t\treturn\n\t\t}\n\t}\n\thttp.Error(w, \"nope\", 400)\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "docker logs from the ingest pod, it restarts every ~9 minutes under load:\n\n2026-07-29T11:02:14.881Z INFO ingest listening on :8080\n2026-07-29T11:04:02.113Z INFO batch accepted device=dev_7781 readings=512\n2026-07-29T11:06:41.552Z WARN write queue depth 8192 (max 8192)\n2026-07-29T11:07:03.918Z WARN write queue depth 8192 (max 8192)\n2026-07-29T11:08:22.004Z WARN gc pause 812ms\n2026-07-29T11:09:15.337Z WARN gc pause 1.44s\n2026-07-29T11:10:58.221Z ERROR liveness probe failed: context deadline exceeded\n2026-07-29T11:11:02.119Z INFO SIGTERM received, draining\n2026-07-29T11:11:32.120Z ERROR drain timed out, 6112 readings dropped\nstream closed EOF for prod/ingest-7d9c4f8b6-x2plq (ingest)\n\nmemory limit is 2Gi and it never reports above 1.3Gi", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "le rapport de l'audit sécurité, section paiements. dis-moi ce qui est vraiment exploitable chez nous :\n\nF-03 — Les clés API marchand sont stockées en clair dans la table `api_keys` (colonne `secret`). Rotation manuelle uniquement.\nF-07 — L'endpoint `/v1/charges` accepte un champ `merchant_id` dans le corps de la requête et ne vérifie pas qu'il correspond au scope du token.\nF-11 — Les webhooks sortants ne signent pas le corps ; les partenaires vérifient uniquement l'adresse IP source.\nF-14 — Les journaux applicatifs contiennent le PAN tronqué (6+4) ainsi que le nom du porteur.\nF-19 — Pas de limite de tentatives sur `/v1/auth/token` (bruteforce possible sur les clés courtes).", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "fr"}
{"prompt": "figma spec for the settlement timeline widget on the merchant dashboard:\n\nSettlement timeline (desktop ≥1024px)\n- Horizontal rail, 4 nodes: Captured → In transit → Paid → Reconciled. Node diameter 20px, 3px stroke.\n- Completed nodes: filled accent, white check glyph. Current node: accent stroke, pulsing 2s ease-in-out halo. Future nodes: 1px muted stroke, no fill.\n- Connector: 2px line, accent up to the current node, muted after. Animate the fill left-to-right over 400ms when a node completes.\n- Under each node: label (text-xs, medium) and timestamp (text-xs, muted). Timestamps in merchant local time, \"—\" when unknown.\n- Failed state: current node turns destructive, connector stops, an inline banner appears below the rail with the failure reason and a Retry link.\n- Below 1024px the rail becomes vertical, nodes left-aligned, 16px gutter.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "handoff notes for the mobile checkout sheet, build it in SwiftUI against our design system:\n\nCheckoutSheet\n- Presented as a `.sheet` with detents [.medium, .large]; drag indicator visible.\n- Header: order total (title2, bold) with the merchant name beneath (footnote, secondary).\n- Instrument list: rows of 56pt, leading icon 24pt, trailing checkmark on the selected row. Tapping a row selects it; long-press opens the remove menu.\n- \"Add payment method\" row pinned to the bottom of the list, tinted accent, chevron trailing.\n- Pay button: full width, 50pt tall, 12pt corner radius, disabled until an instrument is selected, spinner replaces the label while authorizing.\n- Errors surface as an inline red caption under the Pay button, never as an alert.\n- Dynamic Type up to AX3 must not clip the total; the row stack switches to vertical past AX1.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "css for our status chips, currently copy-pasted per status. i want one component out of this without any visual change:\n\n.chip-pending {\n display: inline-flex; align-items: center; gap: 6px;\n padding: 2px 10px; border-radius: 9999px;\n font-size: 12px; font-weight: 500; line-height: 20px;\n background: var(--gray-100); color: var(--gray-700);\n}\n.chip-paid {\n display: inline-flex; align-items: center; gap: 6px;\n padding: 2px 10px; border-radius: 9999px;\n font-size: 12px; font-weight: 500; line-height: 20px;\n background: var(--green-100); color: var(--green-800);\n}\n.chip-failed {\n display: inline-flex; align-items: center; gap: 6px;\n padding: 2px 10px; border-radius: 9999px;\n font-size: 12px; font-weight: 600; line-height: 20px;\n background: var(--red-100); color: var(--red-800);\n}", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "paste from the RFC someone abandoned in march. is any of it still true, and what would you keep?\n\n## Ledger v2 — motivation\nThe current ledger writes one row per order and derives per-instrument amounts at read time. With split tender this stops working: the derivation assumes a single capture. Proposal is double-entry with an `entries` table keyed by (account, batch_id) and a nightly compaction job.\n\n## Open questions\n- Do we backfill history or start fresh at cutover?\n- Compaction under load: the February prototype held locks for 40+ minutes.\n- Reporting reads go through `v_ledger_flat`; do we keep the view or force callers to migrate?\n\n## Not doing\nMulti-currency netting. Real-time reconciliation.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "这是 backfill 脚本的报错，跑到一半就挂了，看不出是数据问题还是代码问题：\n\nTraceback (most recent call last):\n File \"tools/backfill_payments.py\", line 141, in <module>\n main()\n File \"tools/backfill_payments.py\", line 118, in main\n load_chunk(conn, rows)\n File \"tools/backfill_payments.py\", line 87, in load_chunk\n cur.executemany(UPSERT_SQL, [as_tuple(r) for r in rows])\n File \"/usr/lib/python3.12/site-packages/psycopg/cursor.py\", line 742, in executemany\n raise ex.with_traceback(None)\npsycopg.errors.UniqueViolation: duplicate key value violates unique constraint \"fct_payments_pkey\"\nDETAIL: Key (payment_id)=(pay_01HR9K2M) already exists.\n\n已经跑过一次 partial backfill，可能有关系", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "zh"}
{"prompt": "README for the reconciliation CLI is basically the argparse help text. here's what the tool actually takes now, write something a new operator could follow:\n\nusage: reconcile [-h] --since SINCE [--until UNTIL] [--merchant MERCHANT]\n [--source {gateway,ledger,both}] [--batch BATCH] [--dry-run]\n [--out OUT] [--format {csv,ndjson,table}] [--fail-on-drift]\n [--tolerance-cents TOLERANCE_CENTS] [--parallel PARALLEL]\n\nnotes the team knows but never wrote down: --dry-run still writes the audit row; --fail-on-drift is what CI uses; --parallel above 8 starves the pooler; --source both is the only mode that catches missing gateway events; running without --merchant on a full day takes ~25 minutes.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident timeline from last night, in raw form. turn it into the post-mortem doc, our template has Summary / Impact / Timeline / Root cause / Action items:\n\n21:04 alert SettlementLagHigh eu-west-1\n21:07 on-call ack, sees pooler at 200/200 connections\n21:12 manual replay found running for merchant 8812, started 20:51\n21:14 replay killed\n21:18 connections recover to 40/200, lag still climbing\n21:31 second replay discovered on shard 7, also killed\n21:52 locks released, batches start draining\n22:06 queue empty, lag back under 60s\n22:20 confirmed no payouts lost, 41 delayed by >30m\n09:15 next day: guard added to block replay without --batch\n\nimpact numbers: 41 merchants saw delayed payouts, longest 74 minutes, no financial loss", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "grafana panel query plus what support is telling us. something's off and i want the endpoint documented properly once we know:\n\nsum(rate(http_requests_total{route=\"/v1/payouts\",code=~\"4..\"}[5m])) by (code)\n\n code=\"400\" 0.02/s\n code=\"401\" 0.00/s\n code=\"409\" 1.84/s\n code=\"422\" 0.31/s\n\nsupport ticket: \"we get 409 conflict on about a third of our payout creates but the payout is created anyway, so we ignore it now\"\n\nnobody can tell me what 409 means on that route — it isn't in the reference at all", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "pyproject and the CI matrix disagree and the build is amber. smallest change that makes them agree:\n\n[project]\nname = \"acme-pipelines\"\nrequires-python = \">=3.10\"\ndependencies = [\n \"pandas>=2.0,<2.2\",\n \"pyarrow>=14,<15\",\n \"psycopg[binary]>=3.1\",\n \"dbt-core==1.7.9\",\n]\n\n# .github/workflows/ci.yml\nstrategy:\n matrix:\n python: [\"3.10\", \"3.11\", \"3.12\", \"3.13\"]\n\n# failure on 3.13:\nERROR: Could not find a version that satisfies the requirement pandas<2.2,>=2.0\nERROR: No matching distribution found for pandas<2.2,>=2.0", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "helm values diff between staging and prod, i think one of these is why prod is slower:\n\n--- staging/values.yaml\n+++ prod/values.yaml\n@@ -8,7 +8,7 @@ ingest:\n replicas: 4\n- maxUnavailable: 1\n+ maxUnavailable: 0\n@@ -18,10 +18,10 @@ ingest:\n resources:\n requests:\n- cpu: 500m\n- memory: 1Gi\n+ cpu: 250m\n+ memory: 2Gi\n limits:\n- cpu: \"2\"\n+ cpu: 500m\n memory: 2Gi\n@@ -31,6 +31,7 @@ ingest:\n env:\n WRITE_QUEUE_MAX: \"8192\"\n+ GOGC: \"20\"\n BATCH_FLUSH_MS: \"250\"", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "o ficheiro `services/payouts/schedule.py` está assim há dois anos e ninguém lhe toca. o que é que ele faz exatamente, sobretudo a parte dos feriados?\n\ndef next_payout_date(merchant, after=None):\n d = after or date.today()\n delay = merchant.payout_delay_days or 2\n d = d + timedelta(days=delay)\n while d.weekday() >= 5 or d in HOLIDAYS.get(merchant.country, ()):\n d = d + timedelta(days=1)\n if merchant.payout_schedule == \"weekly\":\n while d.weekday() != merchant.payout_weekday:\n d = d + timedelta(days=1)\n elif merchant.payout_schedule == \"monthly\":\n d = d.replace(day=min(merchant.payout_dom, monthrange(d.year, d.month)[1]))\n if d <= (after or date.today()):\n d = (d + timedelta(days=32)).replace(day=merchant.payout_dom)\n return d", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "pt"}
{"prompt": "three call sites, three different ways of building the same gateway request. i want one builder and identical behaviour:\n\n# charges.py\nreq = {\"amount\": amount_cents, \"currency\": cur.lower(), \"source\": token,\n \"capture\": True, \"metadata\": {\"order\": order_id}}\n\n# refunds.py\nreq = dict(amount=amount_cents, currency=cur.upper(), charge=charge_id,\n reason=reason or \"requested_by_customer\",\n metadata={\"order\": str(order_id), \"actor\": actor})\n\n# admin/tools/manual_charge.py\nreq = {}\nreq[\"amount\"] = int(amount * 100)\nreq[\"currency\"] = cur\nreq[\"source\"] = token\nreq[\"capture\"] = capture\nif order_id:\n req[\"metadata\"] = {\"order\": order_id, \"manual\": \"1\"}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "gateway client's retry decorator, which is wrapped around six methods and looks wrong to me but i want it restructured rather than rewritten:\n\ndef with_retries(attempts=3, backoff=0.5):\n def deco(fn):\n @wraps(fn)\n def inner(*a, **kw):\n last = None\n for i in range(attempts):\n try:\n return fn(*a, **kw)\n except (Timeout, ConnectionError) as e:\n last = e\n time.sleep(backoff * (2 ** i))\n except GatewayError as e:\n if e.status >= 500:\n last = e\n time.sleep(backoff * (2 ** i))\n else:\n raise\n raise last\n return inner\n return deco", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "legacy module header, comments included. same behaviour, modern shape, no new deps:\n\n# NOTE(2019): this file predates the payments service split. it talks to the\n# old ledger over a socket. do not remove the sleep on line 40, it is load\n# bearing (see INC-221).\n\nclass LedgerBridge(object):\n def __init__(self, host, port, retries=3):\n self.host = host\n self.port = port\n self.retries = retries\n self._sock = None\n\n def _connect(self):\n if self._sock is None:\n self._sock = socket.create_connection((self.host, self.port), 5)\n time.sleep(0.25)\n return self._sock\n\n def post(self, entry):\n for i in range(self.retries):\n try:\n s = self._connect()\n s.sendall(json.dumps(entry).encode() + b\"\\n\")\n return json.loads(s.recv(65536).decode())\n except Exception:\n self._sock = None\n raise RuntimeError(\"ledger unreachable\")", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "product wrote this in the ticket and i need it broken into shippable pieces with an order and the risky bits called out:\n\nMerchants should be able to set their own payout schedule from the dashboard: daily, weekly on a chosen weekday, or monthly on a chosen day. Changing the schedule must not affect payouts already in flight. Merchants on manual payouts should see the option but disabled with an upsell. We need an audit record of every schedule change including who changed it. Finance wants a report of merchants whose schedule changed in the last 30 days. Support needs the ability to override a schedule temporarily without the merchant seeing it change permanently.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "rate limiting keeps coming up and we keep deferring it. below is what ops observed last week; i want the design written down before any code — where counters live, redis failure behaviour, response headers, and the order we roll it across v1/v2/v3:\n\ntop talkers, 7d, requests per minute at peak:\n merchant 8812 14,200 rpm (bulk order sync every 5 min)\n merchant 4419 9,850 rpm (polling /v1/payouts once per second per store)\n merchant 7702 6,140 rpm (webhook replay loop, self-inflicted)\n everyone else < 900 rpm\n\ntwo of those three took the API down for everyone on tuesday for eleven minutes", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "reconciliation service has grown three responsibilities and i want a target architecture on paper before anyone opens an editor — and while you're in there, the naming is a mess. two deliverables: the design doc first, then the rename pass across the package", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "finance asked for a plain-language explanation of how we compute the payout amount, including fees and reserves, and while writing it i realised the reserve calculation in `payouts/amount.go` doesn't match what we tell merchants. do both: the explainer, and then correct whichever side is wrong", "purpose": "writing", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "tengo dos problemas con el exportador de CSV: primero, nadie sabe qué significan las columnas y hace falta documentación para soporte; segundo, tarda 40 minutos con un millón de filas y creo que hay una consulta N+1 escondida. mira las dos cosas", "purpose": "writing", "secondary": "debugging", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "`services/settlement/` has a `utils.py` that's become a junk drawer — 40 functions, no theme. split it along actual responsibilities, and once that's done i want the module docstrings to actually describe the new layout", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "customers on the merchant dashboard see payout amounts flicker between the cached and fresh value for about a second. i suspect the SWR key, but i also want the loading behaviour on that whole screen rethought so it stops happening in general", "purpose": "debugging", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "since thursday the nightly dbt run fails about half the time on `fct_payments` with a duplicate key, and it started right after the incremental change went in. work out what's actually duplicating, then put a test in the model so it can't happen silently again", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "il y a deux composants `MoneyInput` dans le repo, un dans `packages/ui` et un dans l'app checkout, et ils gèrent les décimales différemment. garde-en un seul, et corrige au passage le padding qui saute sur mobile", "purpose": "refactor", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "fr"}
{"prompt": "`X-Merchant-Id` is accepted on six endpoints and ignored on the rest, which is confusing enough that partners get it wrong constantly. decide what the right behaviour is and write it up, then make the handlers consistent", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "settlement batch size is a magic 500 in four files. bump it to 2000 everywhere and note the change in the runbook so on-call isn't surprised", "purpose": "quickFix", "secondary": "writing", "mixed": true, "difficulty": 0.3, "slice": "mixed", "lang": "en"}
{"prompt": "admin refund modal still says \"Refund order\" when it's a partial. change the copy to reflect the amount, and update the help-centre article that shows the old screenshot", "purpose": "quickFix", "secondary": "writing", "mixed": true, "difficulty": 0.25, "slice": "mixed", "lang": "en"}
{"prompt": "we've been asked to support offline payments on the POS terminals, which means queueing captures on device and reconciling when the network comes back. i have no idea how we handle a capture that expires while queued, or a refund issued against a capture that hasn't reached us yet. i want the whole flow reasoned through — device state machine, server-side dedupe, what the merchant sees in the dashboard while things are pending — before we commit to a shape", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "honestly the biggest problem with our data platform is that nobody knows which tables are canonical. there are three `orders` tables in two schemas, one of them is a view over another, and the ML team reads a fourth one that a contractor built in 2023. i want a plan for consolidating this: what we keep, what we deprecate, how we migrate the readers, and how we stop it happening again", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "firmware team wants over-the-air updates delivered in waves rather than all at once, with automatic halt if the failure rate crosses a threshold. we have 30k devices on flaky rural links, no device-side telemetry beyond a heartbeat, and no way to roll back once slot B is confirmed. what does a safe rollout system look like here, and what has to exist before we can even start", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "engineering handbook has nothing about how we handle money in code and every new hire asks the same questions — cents vs decimals, where rounding happens, why the go service uses int64 and python uses Decimal, what to do about currencies with three decimal places. i'd like a proper page on it with examples from our own codebase", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "public API changelog has been a bulleted list of git commits for a year and partners have told us politely that it's useless. rewrite the last three months of it the way stripe does theirs — what changed, who it affects, what you need to do, with dates and version markers. the raw commits are in `CHANGELOG-raw.md`", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we're deprecating the v1 payouts endpoints in january and i need the comms package: the deprecation notice for the docs site, the email to affected merchants, the response header we'll add, and a short internal note about what support should say when someone calls. tone should be apologetic but firm about the date", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "i've been asked to summarise, for the security review board, exactly what data crosses the boundary between our app servers and the gateway, in what direction, and how long we retain each field. i can read the code but writing this in a form a non-engineer reviewer will accept is the hard part", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "nobody on the team can explain how the fraud score gets into the checkout decision, including the person who wrote it. i want to understand the whole path: what features are computed where, which service calls the model, what happens when the model times out, and whether the fallback is a hard-coded threshold or something smarter", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "two engineers are arguing about whether our webhook delivery is at-least-once or effectively at-most-once given how the worker acks. rather than take sides i'd like someone to actually trace the code path from event write through delivery and ack, and say plainly which it is and where the gap is", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "before the pen test next month, go over how we authenticate merchant API calls end to end — key issuance, storage, the scope check middleware, rotation, and what happens with a revoked key that's already in flight. i'm not asking for changes yet, i want to know where we stand", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "src/sync/reconcile.ts is 900 lines and does fetching, diffing, conflict resolution and persistence in one file. no behaviour should change, but i want it in modules that a new person could navigate, with the conflict rules isolated enough that they're testable on their own", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "every service in the monorepo has its own hand-rolled config loading — env vars in some, a yaml file in others, and the python one reads both plus a json blob from consul. i'd like one approach across all of them, same values resolved the same way, and no service changing behaviour as a result", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "dependency situation in the settlement worker is grim: database handle, gateway client, metrics recorder and feature-flag client all reached through package-level singletons, which is why it's untestable. thread them through as dependencies instead without changing what the worker does", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "device registry needs a bulk enrolment path: operators upload a CSV of serial numbers and MAC addresses, we mint certs for each, and the whole thing has to be resumable because they upload 20k rows over a hotel wifi connection. postgres and a worker queue are fine, no new infra", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "chip radius should be 4px not 9999px", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "en"}
{"prompt": "modal close button sits 2px too high", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "en"}
{"prompt": "console.log left in the payment form", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "receipt footer has last year's address", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "\"recieve\" on the billing empty state", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "turn split_tender on in staging", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "webhook timeout 5s -> 15s", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "pin dbt-core to 1.7.9 in CI", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "CHANGELOG date says 2025, should be 2026", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "en"}
{"prompt": "raise the payout page size to 100", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "das Retry-Limit auf 5 setzen, bitte", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "de"}
{"prompt": "flag icons next to the currency codes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "empty cart art above the fold on mobile", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "disable bulk refund when nothing's selected", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "pricing page hover feels sluggish", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "sticky header on the orders list", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "toast should slide, not fade", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "tighten the mobile card gap to 8px", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "spinner flashes for 40ms, looks broken", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "failed chip amber with an icon", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "`TxnCtx` should be `PaymentContext`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "one money helper, not three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "pull the promo logic out of `buildOrderDraft`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "kill the barrel file in packages/ui", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "`amt` -> `amountCents` across the go service", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "die Test-Helper gehören in ein eigenes Paket", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "de"}
{"prompt": "split settlement/utils.py by responsibility", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "inline the single-use `formatChip` helper", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "who calls `LedgerBridge.post` these days?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "is our webhook signature check constant-time?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "what does `reconcileLedger` do on a partial?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "safe to run two settlement workers?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "¿es seguro exponer `failure_code` a los partners?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "es"}
{"prompt": "PR description for the batching change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "docstring for `next_payout_date`, please", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "one-paragraph summary of the ledger ADR", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "release notes für Firmware 4.2, bitte kurz", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "de"}
{"prompt": "design doc for per-merchant limits", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "milestones for the POS offline work", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "`/v1/devices/{id}/certs` rotate endpoint, go", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "nightly job to expire stale carts", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "cursor pagination on the disputes list", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "dedupe the money helpers, then note it in the changelog", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.35, "slice": "mixed", "lang": "en"}
{"prompt": "scope out the retry redesign, then land step one", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "the usual, for the payouts screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick up the reconciliation thing", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidy", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "otra vez lo del checkout", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "es"}
{"prompt": "can you look at the thing", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "ship the rest of it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "設定画面のあれ、直しておいて", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "ja"}
{"prompt": "payout CSV header says Amount, make it Amount (cents)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "sandbox base URL still points at api-test", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "drop the unused `legacy_gc` column", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "merchant avatar should be circular", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "amount column right-aligned, monospaced", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "keyboard focus ring is invisible on dark", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "payments team wiki has a page called \"How refunds work\" that three different people have edited in three different directions, so it now contradicts itself twice — once about whether partial refunds can exceed the captured amount and once about the 90-day window. sort out what's actually true from the code and rewrite the page so it reads like one person wrote it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "new engineers keep asking why there are two settlement services, and the honest answer is that one was a migration that never finished. i'd like that written down somewhere permanent — what each one owns today, which one is authoritative for which merchant cohort, and the fact that nobody should add features to the old one", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "support is drowning in \"where is my payout\" tickets and half of them are answered by explaining the two-day settlement delay. give me a help-centre article that covers the normal timeline, what a weekend or bank holiday does to it, why a payout can show as pending for longer, and when they should actually escalate to us", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "there's a class in the checkout service called `OrderCoordinator` that everyone is afraid of, about 600 lines, and it's the last thing standing between us and deleting the old cart module. read it and tell me what it's actually responsible for, what state it owns, and which of its methods are dead code — i'm not asking for changes yet", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "a junior on the team opened a PR that adds caching to the merchant lookup and it's got 40 files in it because they also reformatted everything. i can't see the actual change through the noise. tell me what the substantive change is, whether the cache invalidation is sound, and what i should push back on", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "someone on the data team wants to know whether our `fct_payments` model can be trusted for revenue reporting, given that it's incremental and keyed on payment_id with a merge strategy. i'd like an honest read of the model and its tests, including what happens when a payment row is updated after the incremental window has passed", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "error handling in the payments package is a mix of sentinel errors, wrapped errors with %w, and a custom `PaymentError` type that swallows the cause about half the time. i want one convention applied throughout, callers updated, and identical behaviour at the API boundary — same status codes, same response bodies", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our integration tests spin up the whole stack through a 300-line bash script that predates docker compose, and every new test copies a chunk of it. i'd like the setup expressed once, in something maintainable, with the tests themselves unchanged — they should pass exactly as they do now, just faster to reason about", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "analytics team wants event-level payment data in the warehouse within five minutes instead of the current nightly batch, and my instinct is CDC off the postgres WAL, but i haven't thought through schema evolution, backfill, or what we do when the consumer falls behind. talk me through the options and what you'd pick for a team that has no streaming experience", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "roughly once a day a merchant's dashboard shows a payout that then disappears on refresh, and support has three screenshots proving it. the API returns the payout from one replica and not from another as far as i can tell, but our reads are supposed to be routed to the primary for that endpoint. no errors anywhere in the logs", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "invoice preview screen renders server-side HTML in a webview and it's slow, janky on scroll, and completely inaccessible to VoiceOver. rebuild it as a native SwiftUI view backed by the same invoice model, matching the existing PDF layout closely enough that finance won't notice, including the itemised tax rows and the footer", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "we need an internal endpoint that support can hit to force-close a settlement batch early, with a reason and an actor recorded, guarded so it can only run on batches older than an hour and never on one that's mid-transfer. it should return the resulting batch state and the ids of anything it skipped", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "telemetry ingest endpoint currently accepts one reading per request and devices batch by sending 500 requests in a burst. add a batch endpoint that takes up to 1000 readings, rejects the whole batch if any reading fails validation, dedupes on (device_id, captured_at) against the last hour, and returns per-reading status", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt":"AegisQuartzPlayerService 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":"Find AegisBirchMigratorStore's duplicate retry source","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Design handed over a final pass for AegisCraneWorkspaceService, and the basic data flow in projects/aegis/ml/pipeline/features.py already works. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing Tokio deployment\n- keep the work scoped to AegisCraneWorkspaceService and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"AegisFlintTimelineCoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"projects/aegis/lib/codec/frame.cc now contains AegisSummitProxyService's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The AegisHarborIndexStore surface in projects/aegis/apps/console/routes/usage.svelte is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Split AegisDriftConsoleStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"AegisGarnetModalCoordinator: diagnose, then correct","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: AegisCraneWorkspaceStore works, but staging still carries a setting that production corrected last month. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside AegisCraneWorkspaceStore\n- keep public behavior and serialized data unchanged\n\nThe relevant code crosses payments, iOS, Kubernetes. Prefer evidence from the repository and make any assumption explicit.\n\nThe cause and exact value change are already known, so keep this as a contained correction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"En projects/aegis/workers/thumbnail/consumer.ex, AegisOpalRouterStore 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 AegisOpalRouterStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"es"}
{"prompt":"Ticket OPS-41124: retire the legacy replay path for AegisLumenChartFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible AegisLumenChartFlow 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":"# projects/aegis/config/staging.toml\n[worker.aegiscinderauthflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegiscinderauthflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegiscinderauthflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisCinderAuthFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41123\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/aegis/config/staging.toml and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Apparently: # projects/aegis/workers/thumbnail/consumer.ex\n[worker.aegisflinttimelineflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisflinttimelineflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisflinttimelineflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisFlintTimelineFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41121\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Align AegisFlintTimelineFlow'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":"Bring AegisIrisBatchStore'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":"Release verification found a single stale AegisRainfallDBService value; the cause, desired value, and affected assertion are already agreed. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current Tokio operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"AegisPrismCacheStore 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- keep public behavior and serialized data unchanged\n- retain the current Tokio operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes 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":"Two asks around AegisEmberRelayCoordinator: (1) assess ownership and failure handling in projects/aegis/crates/index/src/segment.rs; (2) capture the contract and rollback note for consumers. Keep public behavior and serialized data unchanged, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/aegis/Sources/App/SessionStore.swift b/projects/aegis/Sources/App/SessionStore.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/aegis/Sources/App/SessionStore.swift\n+++ b/projects/aegis/Sources/App/SessionStore.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 AegisRainfallDBCoordinator'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":"AegisQuartzPlayerCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"AegisFrostPanelCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Please turn AegisFrostPanelService's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Describe AegisWillowCodecStore's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"AegisMoonlitSDKCoordinator: sequence, then restructure","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"AegisOrbitSyncCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Lately: // projects/aegis/apps/console/routes/usage.svelte\nfinal class AegisMarbleTokenFlowCoordinator {\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 AegisMarbleTokenFlow 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":"Oddly: // projects/aegis/ui/settings/PrivacyPane.tsx\nfinal class AegisDriftConsoleFlowCoordinator {\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 AegisDriftConsoleFlow; 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":"AegisCoralUploadCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Summarize the AegisSpruceDaemonService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for AegisFlintTimelineStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"For AegisEchoRegistryCoordinator, separate AegisEchoRegistryCoordinator's policy from transport without behavior changes; once that is complete, correct the known stale timeout beside it. Work from projects/aegis/src/sync/reconcile.ts, stay with PostgreSQL 17, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-41153\n\n08:02 deploy AegisCedarPolicyCoordinator 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 AegisCedarPolicyCoordinator 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-41151: finish the compact AegisJuniperCLICoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/aegis/ui/settings/PrivacyPane.tsx\nFramework: NATS JetStream\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 AegisJuniperCLICoordinator's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Currently: projects/aegis/apps/console/routes/usage.svelte 里的 AegisMarbleTokenService 最近在 PostgreSQL 17 流程中出现间歇性问题。 请实现幂等 endpoint，包含持久 cursor、tenant 鉴权、spans 和 retry 测试。\n\n约束：\n- 继续使用 PostgreSQL 17\n- 保持兼容性和取消语义\n- 改动只限于 AegisMarbleTokenService","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"zh"}
{"prompt":"Split projects/aegis/workers/thumbnail/consumer.ex by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current AegisNovaPickerStore design actually guarantees what its callers assume. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside AegisNovaPickerStore\n- keep public behavior and serialized data unchanged\n\nThe relevant code crosses payments, iOS, Kubernetes. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a AegisAmberFilterService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/aegis/Sources/App/SessionStore.swift b/projects/aegis/Sources/App/SessionStore.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/aegis/Sources/App/SessionStore.swift\n+++ b/projects/aegis/Sources/App/SessionStore.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\nRead the artifact above as a skeptical reviewer. Is AegisPrismCacheFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"UI ticket DES-41145: finish the compact AegisAcornWidgetFlow filter experience\n\nRoute: /catalog/search\nSource: projects/aegis/app/src/main/SyncWorker.kt\nFramework: PostgreSQL 17\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\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Use the UI evidence to complete AegisAcornWidgetFlow'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":"Incident timeline — INC-41115\n\n08:02 deploy AegisSableParserFlow 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 AegisSableParserFlow 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":"AegisIrisBatchCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"AegisVelaDrawerCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'AegisMicaProfileFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[AegisMicaProfileFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/aegis/infra/modules/edge/main.tf:144: error: -[AegisMicaProfileFlowTests 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 '-[AegisMicaProfileFlowTests 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\nFind the source of this AegisMicaProfileFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Test Suite 'AegisEmberRelayFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[AegisEmberRelayFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/aegis/pkg/cache/lease.rs:144: error: -[AegisEmberRelayFlowTests 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 '-[AegisEmberRelayFlowTests 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\nBring AegisEmberRelayFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Today: Incident timeline — INC-41119\n\n08:02 deploy AegisNimbusFormFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the AegisNimbusFormFlow 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":"Unifie les validateurs de AegisNimbusFormService","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"fr"}
{"prompt":"Why is AegisMapleQueueService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Context: # projects/aegis/db/migrations/20260730_events.sql\n[worker.aegisledgergatecoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisledgergatecoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisledgergatecoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisLedgerGateCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41150\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/aegis/db/migrations/20260730_events.sql and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Move AegisEmberRelayStore behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-41132: retire the legacy replay path for AegisMapleQueueFlow\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 AegisMapleQueueFlow 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":"We need to move AegisQuartzPlayerStore from the legacy store to NATS JetStream. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Draft AegisSpruceDaemonStore's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"AegisBirchMigratorService's SyncWorker.kt needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"The next client release depends on a new AegisNovaPickerService capability in projects/aegis/internal/auth/refresh.go, with WebGPU already chosen by the platform group. Implement the endpoint and durable cursor, enforce tenant authorization and idempotency, emit useful spans, cap work per request, and include focused tests for retries, cancellation, and malformed cursors.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing WebGPU deployment\n- keep the work scoped to AegisNovaPickerService and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"AegisMarbleTokenCoordinator: handle the lingering thing","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Clarify AegisEchoRegistryStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Where did AegisWillowCodecService's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Background: UI ticket DES-41113: finish the compact AegisOspreyJobFlow filter experience\n\nRoute: /catalog/search\nSource: projects/aegis/packages/api/openapi.yaml\nFramework: SQLite\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Bring AegisOspreyJobFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"AegisNovaPickerCoordinator is blocking the next release because two validators with subtly different error strings. I need two concrete outcomes from a single pass: finish AegisNovaPickerCoordinator's responsive empty and retry states, and capture the contract and rollback note for consumers. Use the existing WebGPU conventions in projects/aegis/infra/modules/edge/main.tf; keep public behavior and serialized data unchanged. 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":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Production says AegisCloudReconcilerStore is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current SQLite operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Two engineers disagree about whether AegisFernSnapshotStore's cache is authoritative. Walk the reads and writes in projects/aegis/cmd/exporter/main.py and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Before we approve AegisSlateEditorStore, assess whether two validators with subtly different error strings is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Fresh release brief for AegisPrismCacheCoordinator:\n- primary outcome: change AegisPrismCacheCoordinator'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/aegis/Sources/CLI/Commands/Doctor.swift\n- platform constraint: Tokio\n- known complication: a misleading timeout name used in five packages\n\nBoth results are required, but they should remain independently reviewable. Keep public behavior and serialized data unchanged; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Question: diff --git a/projects/aegis/db/migrations/20260730_events.sql b/projects/aegis/db/migrations/20260730_events.sql\nindex 62d71aa..90f3c1e 100644\n--- a/projects/aegis/db/migrations/20260730_events.sql\n+++ b/projects/aegis/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\nWire AegisEchoRegistryFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-41142: retire the legacy replay path for AegisBeaconStoreFlow\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 AegisBeaconStoreFlow, 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":"In projects/aegis/ui/settings/PrivacyPane.tsx hat AegisOpalRouterService ein sporadisches Problem im NATS JetStream-Ablauf. Verfolge Queue, Scheduler und Abbruch, vergleiche Hypothesen und finde die Ursache vor jeder Änderung.\n\nRandbedingungen:\n- NATS JetStream weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf AegisOpalRouterService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um AegisOpalRouterService mit NATS JetStream kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"The API work is done; what remains for AegisSableParserStore 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 AegisSableParserStore\n- keep public behavior and serialized data unchanged\n\nThe relevant code crosses payments, iOS, Kubernetes. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"A previously stable test around AegisSummitProxyStore 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":"For AegisBasilRunnerCoordinator, produce a consumer guide for AegisBasilRunnerCoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/aegis/services/ledger/replay.go, stay with WebGPU, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Security flagged AegisTideWorkerService for a read-only pass because its PostgreSQL 17 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- keep public behavior and serialized data unchanged\n- retain the current PostgreSQL 17 operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"# projects/aegis/cmd/exporter/main.py\n[worker.aegiscraneworkspacecoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegiscraneworkspacecoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegiscraneworkspacecoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisCraneWorkspaceCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41159\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/aegis/cmd/exporter/main.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Before we approve AegisLedgerGateStore, assess whether two validators with subtly different error strings is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"projects/aegis/packages/api/openapi.yaml 里的 AegisCoralUploadStore 最近在 SQLite 流程中出现间歇性问题。 请给出阶段、兼容层、指标、rollback 和 ownership，先不要修改代码。\n\n约束：\n- 继续使用 SQLite\n- 保持兼容性和取消语义\n- 改动只限于 AegisCoralUploadStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Observation: # projects/aegis/lib/codec/frame.cc\n[worker.aegisdeltacanvasflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisdeltacanvasflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisdeltacanvasflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisDeltaCanvasFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41116\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/aegis/lib/codec/frame.cc. 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":"Constraint: projects/aegis/pkg/cache/lease.rs now contains AegisCloudReconcilerFlow's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up AegisTideWorkerCoordinator. First, separate AegisTideWorkerCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/aegis/src/sync/reconcile.ts, which follows PostgreSQL 17 conventions and currently suffers from duplicate retries after a network handoff. Keep public behavior and serialized data unchanged.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Teach AegisMosaicGridStore to verify signed continuation tokens, reject cross-tenant cursors, and rotate keys without invalidating tokens issued during the overlap window.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"AegisBeaconStoreCoordinator: polish the last piece","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Why does AegisFrostPanelStore's WebGPU worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Request: Ticket OPS-41139: retire the legacy replay path for AegisIrisBatchFlow\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 AegisIrisBatchFlow 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":"Spell AegisDriftConsoleService's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Goal: // projects/aegis/apps/console/routes/usage.svelte\nfinal class AegisHarborIndexCoordinatorCoordinator {\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 AegisHarborIndexCoordinator by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"AegisDeltaCanvasCoordinator: polish, then correct","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Memory attributed to AegisPineMetricsStore 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":"Does AegisCopperBridgeFlow 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":"Support wants the behavior in projects/aegis/app/src/main/SyncWorker.kt recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Flip AegisMoonlitSDKStore's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"I inherited AegisOspreyJobStore and need a careful read of projects/aegis/config/staging.toml 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- keep public behavior and serialized data unchanged\n- stay compatible with the existing SQLite deployment\n- keep the work scoped to AegisOspreyJobStore and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Unify the AegisMicaProfileStore validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Symptom: Two engineers disagree about whether AegisIrisBatchService's cache is authoritative. Walk the reads and writes in projects/aegis/cmd/exporter/main.py and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"AegisAtlasSearchCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Bump AegisLumenChartService's timeout to 30s","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-41125: finish the compact AegisBirchMigratorFlow filter experience\n\nRoute: /catalog/search\nSource: projects/aegis/app/src/main/SyncWorker.kt\nFramework: PostgreSQL 17\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\nBring AegisBirchMigratorFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Read projects/aegis/pkg/cache/lease.rs and tell me whether AegisSlateEditorService 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":"Ist AegisNimbusFormStore sicher?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"de"}
{"prompt":"Headsup: # projects/aegis/workers/thumbnail/consumer.ex\n[worker.aegisorbitsyncflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisorbitsyncflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisorbitsyncflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisOrbitSyncFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41141\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/aegis/workers/thumbnail/consumer.ex and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"pasted-context","lang":"en"}
{"prompt":"FYI: Ticket OPS-41112: retire the legacy replay path for AegisNovaPickerFlow\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 AegisNovaPickerFlow 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":"Is there a cleaner way to separate AegisOrbitSyncStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Set AegisRavenSessionStore's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"A flaky failure around AegisPineMetricsService 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 AegisPineMetricsService\n- keep public behavior and serialized data unchanged\n\nThe relevant code crosses payments, iOS, Kubernetes. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-41111\n\n08:02 deploy AegisOpalRouterFlow 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 AegisOpalRouterFlow 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":"Ticket OPS-41148: retire the legacy replay path for AegisSlateEditorFlow\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 AegisSlateEditorFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"AegisSlateEditorCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Meanwhile: # projects/aegis/Sources/App/SessionStore.swift\n[worker.aegisveladrawerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisveladrawerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisveladrawerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisVelaDrawerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41134\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/aegis/Sources/App/SessionStore.swift. 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":"Sequence AegisGarnetModalService's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current AegisHarborIndexService design actually guarantees what its callers assume. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside AegisHarborIndexService\n- keep public behavior and serialized data unchanged\n\nThe relevant code crosses payments, iOS, Kubernetes. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Locally: Ticket OPS-41144: retire the legacy replay path for AegisWrenExportFlow\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 AegisWrenExportFlow 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":"Is there a cleaner way to separate AegisCedarPolicyFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Production: Ticket OPS-41136: retire the legacy replay path for AegisSummitProxyFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible AegisSummitProxyFlow 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":"AegisWrenExportCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"AegisSummitProxyCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Staging: projects/aegis/engine/render/atlas.cpp has grown through several launches, and AegisCopperBridgeService 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- keep public behavior and serialized data unchanged\n- stay compatible with the existing NATS JetStream deployment\n- keep the work scoped to AegisCopperBridgeService and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Corrija o timeout de AegisBasilRunnerService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"pt"}
{"prompt":"CI: Ticket OPS-41118: retire the legacy replay path for AegisMoonlitSDKFlow\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 AegisMoonlitSDKFlow 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":"Security flagged AegisAsterWebhookService for a read-only pass because its WebGPU 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- keep public behavior and serialized data unchanged\n- retain the current WebGPU operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"The name pendingAck means two different things across AegisCopperBridgeStore's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Describe AegisSableParserService's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"Why is AegisDeltaCanvasService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"A flaky failure around AegisCloudReconcilerService 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 AegisCloudReconcilerService\n- keep public behavior and serialized data unchanged\n\nThe relevant code crosses payments, iOS, Kubernetes. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/aegis/crates/index/src/segment.rs b/projects/aegis/crates/index/src/segment.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/aegis/crates/index/src/segment.rs\n+++ b/projects/aegis/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\nRead the artifact above as a skeptical reviewer. Is AegisAtlasSearchFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"# projects/aegis/web/components/FilterDrawer.vue\n[worker.aegisfrostpanelflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisfrostpanelflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisfrostpanelflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisFrostPanelFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41147\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/aegis/web/components/FilterDrawer.vue and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Two asks around AegisBirchMigratorCoordinator: (1) change AegisBirchMigratorCoordinator's known staging timeout from 15 to 30 seconds; (2) give the existing implementation a read-only safety pass. Keep public behavior and serialized data unchanged, and leave a clear boundary between the resulting artifacts or edits.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Atlas: Is there a cleaner way to separate AegisCraneWorkspaceFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"En projects/aegis/config/staging.toml, AegisCedarPolicyService tiene un problema intermitente en el flujo de SQLite. Añade el endpoint idempotente con cursor durable, autorización tenant, spans y tests de retry.\n\nRestricciones:\n- seguir con SQLite\n- conservar compatibilidad y cancelación\n- limitar el cambio a AegisCedarPolicyService Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con SQLite alrededor de AegisCedarPolicyService.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"es"}
{"prompt":"Three teams extended AegisJuniperCLIService 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- keep public behavior and serialized data unchanged\n- retain the current NATS JetStream operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes 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":"# projects/aegis/ml/pipeline/features.py\n[worker.aegisfernsnapshotflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisfernsnapshotflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisfernsnapshotflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisFernSnapshotFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41149\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/aegis/ml/pipeline/features.py. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Could the reasoning behind AegisWrenExportService's Tokio choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"AegisWrenExportStore has four wrappers that only translate the same error enum. Collapse them into one adapter and preserve every public case, message, and metric label. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"We need to move AegisVelaDrawerStore from the legacy store to Tokio. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"I inherited AegisDeltaCanvasStore and need a careful read of projects/aegis/engine/render/atlas.cpp 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- keep public behavior and serialized data unchanged\n- stay compatible with the existing NATS JetStream deployment\n- keep the work scoped to AegisDeltaCanvasStore and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Split projects/aegis/web/components/FilterDrawer.vue by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for AegisOpalRouterCoordinator:\n- primary outcome: separate AegisOpalRouterCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/aegis/workers/thumbnail/consumer.ex\n- platform constraint: NATS JetStream\n- known complication: a query plan that changes after statistics refresh\n\nBoth results are required, but they should remain independently reviewable. Keep public behavior and serialized data unchanged; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"The behavior of AegisGarnetModalStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/aegis/web/components/FilterDrawer.vue. 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- keep public behavior and serialized data unchanged\n- retain the current WebGPU operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"AegisRavenSessionCoordinator: sequence, then ship","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/aegis/src/sync/reconcile.ts b/projects/aegis/src/sync/reconcile.ts\nindex 62d71aa..90f3c1e 100644\n--- a/projects/aegis/src/sync/reconcile.ts\n+++ b/projects/aegis/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\nRead the artifact above as a skeptical reviewer. Is AegisRavenSessionFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"We need to move AegisBeaconStoreService from the legacy store to WebGPU. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"AegisAtlasSearchStore has four wrappers that only translate the same error enum. Collapse them into one adapter and preserve every public case, message, and metric label. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Match AegisMoonlitSDKService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"AegisCinderAuthCoordinator: sequence, then ship","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"vague-eval","lang":"en"}
{"prompt":"Design handed over a final pass for AegisLedgerGateService, and the basic data flow in projects/aegis/src/sync/reconcile.ts already works. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to AegisLedgerGateService and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Polish the AegisEchoRegistryService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Beacon: # projects/aegis/db/migrations/20260730_events.sql\n[worker.aegistideworkerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegistideworkerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegistideworkerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisTideWorkerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41110\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/aegis/db/migrations/20260730_events.sql. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Support wants the behavior in projects/aegis/ui/settings/PrivacyPane.tsx recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Cinder: We need to move AegisPineMetricsFlow from the legacy store to WebGPU. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Delta: // projects/aegis/services/ledger/replay.go\nfinal class AegisMosaicGridFlowCoordinator {\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\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Split AegisMosaicGridFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Read projects/aegis/db/migrations/20260730_events.sql and tell me whether AegisAmberFilterStore 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":"Make AegisFlintTimelineService keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"AegisFernSnapshotCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Could the reasoning behind AegisAtlasSearchService's SQLite choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"AegisSpruceDaemonCoordinator needs a paired pass: lay out a staged migration for AegisSpruceDaemonCoordinator, plus then implement the bounded durable-cursor handler. Use projects/aegis/lib/codec/frame.cc as the source of truth, preserve the NATS JetStream contract, and avoid unrelated cleanup.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"AegisMapleQueueCoordinator needs a paired pass: lay out a staged migration for AegisMapleQueueCoordinator, plus then implement the bounded durable-cursor handler. Use projects/aegis/infra/modules/edge/main.tf as the source of truth, preserve the WebGPU contract, and avoid unrelated cleanup.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Ember: diff --git a/projects/aegis/services/ledger/replay.go b/projects/aegis/services/ledger/replay.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/aegis/services/ledger/replay.go\n+++ b/projects/aegis/services/ledger/replay.go\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is AegisGarnetModalFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"AegisRainfallDBStore occasionally exhibits cancellation being swallowed at the repository boundary, but only after a reconnect. Follow the data and cancellation paths in projects/aegis/Sources/App/SessionStore.swift and identify the cause before changing anything.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-41133: finish the compact AegisKiteSchedulerFlow filter experience\n\nRoute: /catalog/search\nSource: projects/aegis/packages/api/openapi.yaml\nFramework: SQLite\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 AegisKiteSchedulerFlow'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":"Frost: // projects/aegis/crates/index/src/segment.rs\nfinal class AegisCloudReconcilerCoordinatorCoordinator {\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 AegisCloudReconcilerCoordinator; 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":"Garnet: The AegisMosaicGridService empty state in projects/aegis/services/ledger/replay.go needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a AegisVelaDrawerService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"AegisNimbusFormCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"AegisEmberRelayService leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Harbor: projects/aegis/config/staging.toml の AegisCoralUploadService で、SQLite の flow に断続的な問題が起きています。 queue、scheduler、cancel 経路を追い、仮説を比較して、変更前に原因を特定してください。\n\n制約:\n- SQLite を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は AegisCoralUploadService のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Iris: The AegisBeaconStoreStore 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":"A copied hex color in AegisAcornWidgetStore lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Two asks around AegisDriftConsoleCoordinator: (1) assess ownership and failure handling in projects/aegis/workers/thumbnail/consumer.ex; (2) capture the contract and rollback note for consumers. Keep public behavior and serialized data unchanged, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Support wants the behavior in projects/aegis/services/ledger/replay.go recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Juniper: # projects/aegis/lib/codec/frame.cc\n[worker.aegiscopperbridgecoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegiscopperbridgecoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegiscopperbridgecoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisCopperBridgeCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41156\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/aegis/lib/codec/frame.cc and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"2026-07-30T08:14:11.409Z level=info service=aegisbasilrunnerflow pod=aegisbasilrunnerflow-7cf8 request_id=41127 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=aegisbasilrunnerflow request_id=41127 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=aegisbasilrunnerflow request_id=41127 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=aegisbasilrunnerflow request_id=41127 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=aegisbasilrunnerflow request_id=41127 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=aegisbasilrunnerflow request_id=41127 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=aegisbasilrunnerflow request_id=41127 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=aegisbasilrunnerflow request_id=41127 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 AegisBasilRunnerFlow failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-41157: retire the legacy replay path for AegisAsterWebhookCoordinator\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 AegisAsterWebhookCoordinator 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":"Split AegisCinderAuthStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"For AegisLumenChartCoordinator, lay out a staged migration for AegisLumenChartCoordinator; once that is complete, consolidate the duplicated normalization paths without changing behavior. Work from projects/aegis/Sources/App/SessionStore.swift, stay with Tokio, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Payments: Support wants the behavior in projects/aegis/app/src/main/SyncWorker.kt recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"AegisMosaicGridCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Give AegisKiteSchedulerService a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-41143: finish the compact AegisCoralUploadFlow filter experience\n\nRoute: /catalog/search\nSource: projects/aegis/config/staging.toml\nFramework: SQLite\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\nBring AegisCoralUploadFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Kestrel: Split projects/aegis/packages/api/openapi.yaml by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"AegisWillowCodecCoordinator needs a paired pass: lay out a staged migration for AegisWillowCodecCoordinator, plus then implement the bounded durable-cursor handler. Use projects/aegis/cmd/exporter/main.py as the source of truth, preserve the Tokio contract, and avoid unrelated cleanup.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-41126: retire the legacy replay path for AegisSpruceDaemonFlow\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\nDeliver the AegisSpruceDaemonFlow 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":"Corrige le timeout de AegisBasilRunnerStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"fr"}
{"prompt":"AegisMicaProfileCoordinator: document, then correct","purpose":"writing","secondary":"debugging","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Two deliverables are holding up AegisOspreyJobCoordinator. First, produce a consumer guide for AegisOspreyJobCoordinator. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/aegis/config/staging.toml, which follows SQLite conventions and currently suffers from memory growth during hour-long imports. Keep public behavior and serialized data unchanged.\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":"writing","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Map AegisRavenSessionService's ownership split","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Incident timeline — INC-41129\n\n08:02 deploy AegisWillowCodecFlow 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À partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Turn the material above into a concise AegisWillowCodecFlow 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":"AegisSableParserCoordinator is blocking the next release because stale cursors when a page is resumed. I need two concrete outcomes from a single pass: finish AegisSableParserCoordinator's responsive empty and retry states, and capture the contract and rollback note for consumers. Use the existing PostgreSQL 17 conventions in projects/aegis/app/src/main/SyncWorker.kt; keep public behavior and serialized data unchanged. 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":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a deadlock that appears only during shutdown in AegisRainfallDBFlow, 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":"The AegisFernSnapshotService surface in projects/aegis/ml/pipeline/features.py is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Rename AegisLumenChartStore's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"projects/aegis/workers/thumbnail/consumer.ex の AegisJuniperCLIFlow で、NATS JetStream の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- NATS JetStream を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は AegisJuniperCLIFlow のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Any races in AegisMicaProfileService?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"projects/aegis/src/sync/reconcile.ts has grown through several launches, and AegisTideWorkerStore 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- keep public behavior and serialized data unchanged\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to AegisTideWorkerStore and its direct tests\n\nThis repository spans payments, iOS, Kubernetes; use its existing conventions rather than importing a new abstraction.\n\nThe individual edits look tiny, but the semantic cleanup spans the repository and must preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"AegisAmberFilterCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"For AegisKiteSchedulerCoordinator, ship the idempotent AegisKiteSchedulerCoordinator replay endpoint; once that is complete, capture the contract and rollback note for consumers. Work from projects/aegis/config/staging.toml, stay with SQLite, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Lumen: # projects/aegis/engine/render/atlas.cpp\n[worker.aegisquartzplayerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.aegisquartzplayerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.aegisquartzplayerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.AegisQuartzPlayerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-41146\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/aegis/engine/render/atlas.cpp. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Summarize the AegisMapleQueueStore changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The behavior of AegisOspreyJobService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/aegis/packages/api/openapi.yaml. 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- keep public behavior and serialized data unchanged\n- retain the current SQLite operational envelope\n\nSeveral teams work in this payments, iOS, Kubernetes monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/aegis/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.8,"slice":"core","lang":"en"}
{"prompt":"Em projects/aegis/app/src/main/SyncWorker.kt, o AegisMarbleTokenStore tem um problema intermitente no fluxo de PostgreSQL 17. Finalize o layout responsivo, estados vazio e retry, foco por teclado, dark mode e reduced motion.\n\nRestrições:\n- continuar com PostgreSQL 17\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao AegisMarbleTokenStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"pt"}
{"prompt":"AegisAcornWidgetCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Any races in AegisPrismCacheService?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Queue AegisKiteSchedulerStore's expired sessions","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Maple: Ticket OPS-41140: retire the legacy replay path for AegisAmberFilterFlow\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 AegisAmberFilterFlow 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":"Nimbus: Ticket OPS-41152: retire the legacy replay path for AegisPineMetricsCoordinator\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 AegisPineMetricsCoordinator 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":"Investigate the AegisCinderAuthService hang","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
data/round2-02.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "a consultant reviewed our compose code and left a list of \"performance issues\" that i'm not sure i believe — unstable lambdas, missing keys in lazy lists, derivedStateOf everywhere, and a claim that our whole schedule screen recomposes on every scroll tick. check the actual code and tell me which of those are real for us", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "our accessibility story on android is \"we ran the scanner once\". i'd like a plan for getting the booking flow to a state we could defend in a procurement review, and as a first step the slot picker fixed properly — content descriptions, touch targets, focus order, the lot", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "the retry delays array in constants.ts goes 1s 2s 4s 8s but the client only ever reads the first two, wire the rest up", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "appointment reminders stopped going out saturday night, here's the sidekiq log around then:\n\n2026-07-25T22:58:01.114Z pid=41 tid=9x8 class=ReminderJob jid=8f2b1c INFO: start\n2026-07-25T22:58:01.882Z pid=41 tid=9x8 class=ReminderJob jid=8f2b1c INFO: 412 reminders queued\n2026-07-25T23:00:00.004Z pid=41 tid=a02 class=ReminderJob jid=91cc40 INFO: start\n2026-07-25T23:00:00.119Z pid=41 tid=a02 class=ReminderJob jid=91cc40 INFO: 0 reminders queued\n2026-07-25T23:02:00.006Z pid=41 tid=b71 class=ReminderJob jid=aa1902 INFO: start\n2026-07-25T23:02:00.101Z pid=41 tid=b71 class=ReminderJob jid=aa1902 INFO: 0 reminders queued\n2026-07-26T00:00:00.008Z pid=41 tid=c19 class=ReminderJob jid=bb7711 INFO: start\n2026-07-26T00:00:00.093Z pid=41 tid=c19 class=ReminderJob jid=bb7711 INFO: 0 reminders queued\n\nno errors, it just decided there was nothing to send", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "we need the waitlist offer job written, here's what product agreed to:\n\n- triggered when an appointment is cancelled or a slot opens through a reschedule\n- eligible entries: same clinic, same day, provider matches or the entry says \"any\", not expired, not already holding an offer\n- FIFO by created_at, one offer at a time, 2-hour acceptance window (configurable per clinic)\n- offer goes out on the patient's preferred channel; if that channel fails, fall back to the other and record it\n- if the window passes, the offer moves to the next eligible entry automatically\n- if nobody accepts within 24 hours, the slot goes back to normal availability and we stop\n- everything must survive a redeploy mid-window\n\nrails, sidekiq, postgres — same patterns as the reminder job", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "a mid-size clinic reported that dragging an appointment to a new time occasionally moves a different appointment instead, maybe once a day, and we have no way to reproduce it. the drag layer keys blocks by index in some places and by id in others, which smells, but i can't connect that to what they're seeing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our error codes are documented nowhere and support guesses; produce the table from `app/errors/` with a human explanation per code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "the endpoint for cancelling an appointment takes a reason enum that the mobile app doesn't send, so 40% of cancellations are `unspecified`, and product wants that fixed properly rather than defaulted", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "we have to support double-booking because three of our five pilot clinics deliberately overbook for no-show buffer, and our model currently forbids overlapping appointments at the database level with an exclusion constraint. i need to know what changes, how the schedule screen renders it, what the API says when someone books into an occupied slot, and how we let clinics that hate the idea keep the current behaviour", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "appointment blocks on the week grid are laid out with absolute positioning and magic offsets, so on a 13-inch laptop the 8am row is cut off and on a 4k monitor there's a band of dead space at the bottom. make the grid size to the viewport properly, keeping the existing look at the default zoom", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "compose theme file, inherited from a contractor. before i extend it for the dark palette i want to know what i'm dealing with:\n\n@Composable\nfun ClinicalTheme(\n darkTheme: Boolean = isSystemInDarkTheme(),\n dynamicColor: Boolean = true,\n content: @Composable () -> Unit\n) {\n val colorScheme = when {\n dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {\n val ctx = LocalContext.current\n if (darkTheme) dynamicDarkColorScheme(ctx) else dynamicLightColorScheme(ctx)\n }\n darkTheme -> DarkColors\n else -> LightColors\n }\n val view = LocalView.current\n if (!view.isInEditMode) {\n SideEffect {\n val window = (view.context as Activity).window\n window.statusBarColor = colorScheme.primary.toArgb()\n WindowCompat.getInsetsController(window, view).isAppearanceLightStatusBars = !darkTheme\n }\n }\n MaterialTheme(colorScheme = colorScheme, typography = ClinicalType, content = content)\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "unity console after the build, the frame time doubled and i think one of these is the culprit:\n\n[Profiler] PlayerLoop 33.4ms\n ├ Update.ScriptRunBehaviourUpdate 21.8ms\n │ ├ EnemySpawner.Update() 14.2ms (GC.Alloc 1.4 MB)\n │ ├ PathfindingManager.Update() 5.1ms\n │ └ HUDController.Update() 2.4ms (GC.Alloc 220 KB)\n ├ PreLateUpdate.DirectorUpdate 3.1ms\n └ Render.OpaqueGeometry 7.6ms\n\nWarning: Instantiating 'Bullet(Clone)' 240 times this frame\nWarning: GameObject.FindWithTag called from EnemySpawner.Update()\nWarning: Camera.main accessed 240 times this frame\n[GC] Incremental GC collected 3.2 MB in 8.1ms", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "play console ANR cluster from last week's release, 0.9% of sessions:\n\nANR in io.clinicly.app (io.clinicly.app/.MainActivity)\nPID: 4471\nReason: Input dispatching timed out (Application does not respond)\n\n\"main\" prio=5 tid=1 Blocked\n | group=\"main\" sCount=1 dsCount=0 flags=1 obj=0x72b9c4d0\n at io.clinicly.data.SyncCoordinator.awaitIdle(SyncCoordinator.kt:88)\n - waiting to lock <0x0a11c3f2> (a java.lang.Object) held by thread 42\n at io.clinicly.data.AppointmentRepository.refresh(AppointmentRepository.kt:214)\n at io.clinicly.ui.ScheduleViewModel$load$1.invokeSuspend(ScheduleViewModel.kt:66)\n\n\"DefaultDispatcher-worker-3\" prio=5 tid=42 Native\n at android.database.sqlite.SQLiteConnection.nativeExecuteForChangedRowCount(Native method)\n at io.clinicly.data.local.AppointmentDao_Impl.upsertAll(AppointmentDao_Impl.java:181)\n\nlocked <0x0a11c3f2>", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "sentry issue, been firing since the timezone work went in:\n\nActiveRecord::StatementInvalid: PG::DatetimeFieldOverflow: ERROR: date/time field value out of range: \"2026-11-01 02:30:00\"\nHINT: Perhaps you need a different \"datestyle\" setting.\n\n app/models/clinic_hours.rb:41:in `slots_for'\n app/services/appointments/availability.rb:88:in `block in build'\n app/services/appointments/availability.rb:84:in `each'\n app/services/appointments/availability.rb:84:in `build'\n app/controllers/api/v2/availability_controller.rb:19:in `index'\n\n clinic_id: 4412 (America/Santiago)\n requested_date: 2026-11-01\n events: 1,204 in 6 days\n users affected: 38\n\nonly clinics in a handful of timezones, and always on specific dates", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "gradle keeps failing on CI only, works on my machine and on two other laptops:\n\n> Task :app:kaptGenerateStubsReleaseKotlin FAILED\ne: file:///home/runner/work/clinicly/app/src/main/java/io/clinicly/di/AppModule.kt:44:1 error: [Dagger/DuplicateBindings] io.clinicly.data.Clock is bound multiple times:\n @Provides @Singleton io.clinicly.data.Clock io.clinicly.di.AppModule.provideClock()\n @Provides @Singleton io.clinicly.data.Clock io.clinicly.di.TestClockModule.provideClock()\n\nFAILURE: Build failed with an exception.\n* What went wrong:\nExecution failed for task ':app:kaptGenerateStubsReleaseKotlin'.\n> A failure occurred while executing org.jetbrains.kotlin.gradle.internal.KaptExecution\n\n* Try:\n> Run with --stacktrace option to get the stack trace.\n\nBUILD FAILED in 4m 12s", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "PR i'm meant to approve today. it's from someone senior so i want a second opinion before i comment:\n\n@@ -12,6 +12,28 @@ class Appointment < ApplicationRecord\n belongs_to :clinic\n belongs_to :patient\n \n+ after_commit :sync_to_calendar, on: [:create, :update]\n+\n+ def sync_to_calendar\n+ CalendarSyncJob.perform_now(id)\n+ rescue => e\n+ Rails.logger.warn(\"calendar sync failed: #{e.message}\")\n+ end\n+\n+ def self.overlapping(clinic_id, range)\n+ where(clinic_id: clinic_id)\n+ .where(\"tstzrange(starts_at, ends_at) && tstzrange(?, ?)\", range.first, range.last)\n+ end\n+\n scope :upcoming, -> { where(\"starts_at > ?\", Time.current) }\n@@ -41,7 +63,7 @@ class Appointment < ApplicationRecord\n- validates :starts_at, presence: true\n+ validates :starts_at, presence: true, if: -> { !skip_validation }", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "das ist unsere Migration für die Mandantentrennung. Bevor wir sie ausführen: hältst du das für sicher?\n\nclass AddClinicScopeToAppointments < ActiveRecord::Migration[7.1]\n def change\n add_column :appointments, :clinic_id, :bigint\n add_index :appointments, :clinic_id, algorithm: :concurrently\n Appointment.reset_column_information\n Appointment.find_each do |a|\n a.update_column(:clinic_id, a.patient.clinic_id)\n end\n change_column_null :appointments, :clinic_id, false\n add_foreign_key :appointments, :clinics\n end\nend\n\nTabelle hat 22 Millionen Zeilen, Postgres 16, kein Wartungsfenster", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "changelog time, we ship the android app thursday. commits since 3.4:\n\n* a81f22c feat(schedule): week view swipe gestures\n* 4409ba1 fix(sync): don't drop local edits when the server 409s\n* 77c0e19 fix(a11y): talkback reads slot times correctly now\n* 2b1904d chore: bump compose bom to 2026.06.00\n* 9911aa0 feat(booking): waitlist join from a full day\n* 31de770 perf(schedule): remove recomposition storm on day change\n* cc4102b fix(notifications): reminder deep link opened the wrong appointment\n* 6f2b901 chore: crashlytics ndk symbols upload\n* 0091ac4 fix(login): biometric prompt dismissed on first launch\n\nplay store listing, so friendly and short, no commit hashes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "support macro draft below is terrible and i have to send something today. rewrite it:\n\n\"Hi, Thank you for contacting Clinicly Support. Regarding your issue with appointment reminders not being sent, this is caused by the clinic timezone setting being incorrect in your Clinic Settings page which needs to be set correctly by an administrator of your clinic account. Please navigate to Settings > Clinic > Regional and select the correct timezone from the dropdown list and then save the changes and reminders will be sent correctly going forward. Note that appointments already scheduled will not be updated retroactively. Thank you for your patience. Best regards, Clinicly Support Team\"\n\nkeep the facts, lose the bureaucracy, and add the bit about existing appointments needing a manual resend", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "app crashes on API 34 the moment you open notifications settings, and the fix is probably one line:\n\njava.lang.SecurityException: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts\n\tat android.os.Parcel.createExceptionOrNull(Parcel.java:3057)\n\tat android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1826)\n\tat io.clinicly.notifications.ReminderSettingsFragment.onStart(ReminderSettingsFragment.kt:44)\n\ntargetSdk went from 33 to 34 in the last release", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "HUD prefab is a mess of anchors and i've been asked to make it work on ultrawide and on steam deck. current layout values:\n\nCanvas: Scale With Screen Size, ref 1920x1080, match 0.5\nHealthBar: anchor min (0,1) max (0,1), pos (120, -60), size (240, 24)\nAmmoCounter: anchor min (1,1) max (1,1), pos (-140, -60), size (180, 40)\nMinimap: anchor min (1,0) max (1,0), pos (-160, 160), size (280, 280)\nWaveBanner: anchor min (0.5,1) max (0.5,1), pos (0, -40), size (600, 80)\nBossHealth: anchor min (0.5,1) max (0.5,1), pos (0, -140), size (900, 32)\n\nat 21:9 the minimap sits under the bezel on deck and the boss bar overlaps the wave banner", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "clinic phone number missing from the receipt", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "waitlist window default to 90 minutes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "one slot-eligibility function, not three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "kdoc on SyncCoordinator, please", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "is our tenant scoping actually enforced?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "schedule thing again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "there is no document anywhere that says what happens to a patient's data when a clinic leaves us, and both legal and two prospects have now asked. from the code and the ops runbooks, work out what actually happens today — export format, deletion timeline, what stays in backups — and write it up as a page we can hand to a customer without lawyering it first", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand how room assignment picks a room when two appointments could use the same one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "compose app is one gradle module and builds take four minutes on the CI runners, which is starting to hurt. modularising is the obvious answer but i've seen it go badly — circular dependencies, dagger components everywhere, nobody agreeing where things live. what would a sane module structure look like for an app this size, and in what order would you carve it up", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "logcat from a tester's Pixel, the appointment list just goes blank:\n\nE/AndroidRuntime( 8812): FATAL EXCEPTION: main\nE/AndroidRuntime( 8812): Process: io.clinicly.app, PID: 8812\nE/AndroidRuntime( 8812): java.lang.IllegalStateException: Reading a state that was created after the snapshot was taken or in a snapshot that has not yet been applied\nE/AndroidRuntime( 8812): \tat androidx.compose.runtime.snapshots.SnapshotKt.readError(Snapshot.kt:2371)\nE/AndroidRuntime( 8812): \tat androidx.compose.runtime.snapshots.SnapshotStateList.get(SnapshotStateList.kt:88)\nE/AndroidRuntime( 8812): \tat io.clinicly.schedule.DayColumnKt$DayColumn$1$2.invoke(DayColumn.kt:141)\nE/AndroidRuntime( 8812): \tat androidx.compose.foundation.lazy.LazyListKt.items(LazyList.kt:212)\nE/AndroidRuntime( 8812): \tat io.clinicly.schedule.ScheduleScreenKt.ScheduleScreen(ScheduleScreen.kt:88)\nE/AndroidRuntime( 8812): \tat io.clinicly.MainActivity$onCreate$1.invoke(MainActivity.kt:52)\n\nonly reproduces after you rotate while the refresh is in flight", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "rspec is red on main and the diff that broke it is three commits back somewhere:\n\nFailures:\n\n 1) Appointments::Reschedule moves the slot and notifies the patient\n Failure/Error: expect(appointment.reload.starts_at).to eq(new_slot.starts_at)\n\n expected: 2026-08-03 14:00:00.000000000 +0000\n got: 2026-08-03 13:00:00.000000000 +0000\n\n (compared using ==)\n # ./spec/services/appointments/reschedule_spec.rb:41:in `block (2 levels)'\n\n 2) Appointments::Reschedule refuses a slot outside clinic hours\n Failure/Error: expect { subject }.to raise_error(OutsideClinicHours)\n expected OutsideClinicHours, got #<ActiveRecord::RecordInvalid: Validation failed: Starts at must be in the future>\n # ./spec/services/appointments/reschedule_spec.rb:63:in `block (2 levels)'\n\nFinished in 1 minute 12.4 seconds (files took 6.1 seconds to load)\n412 examples, 2 failures\n\nboth of these passed on friday and nobody touched the scheduler", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ログにこれが延々と出ていて、予約の同期が止まります。原因が分かりません:\n\nW/SyncWorker(3312): retrying sync attempt=4 delay=8000ms\nW/SyncWorker(3312): retrying sync attempt=5 delay=16000ms\nE/SyncWorker(3312): sync failed: retrofit2.HttpException: HTTP 409 Conflict\nE/SyncWorker(3312): \tat io.clinicly.net.ApiClient$sync$2.invokeSuspend(ApiClient.kt:141)\nE/SyncWorker(3312): \tat kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)\nI/WM-WorkerWrapper(3312): Worker result RETRY for Work [ id=8f21-c0aa-4771, tags={ sync } ]\nI/WM-Processor(3312): Processor stopping foreground work sync\nW/SyncWorker(3312): retrying sync attempt=6 delay=32000ms\n\nサーバー側のログでは 409 は「revision mismatch」と書いてあります", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "ja"}
{"prompt": "crash reporter groups these together but the stacks look unrelated to me:\n\nNullReferenceException: Object reference not set to an instance of an object\n at Clinicly.Game.WaveDirector.OnEnemyKilled (Clinicly.Game.Enemy e) [0x00021] in /Assets/Scripts/WaveDirector.cs:118\n at Clinicly.Game.Enemy.Die () [0x0000c] in /Assets/Scripts/Enemy.cs:88\n at Clinicly.Game.DamageSystem.Apply (Clinicly.Game.Enemy target, System.Single amount) [0x00044] in /Assets/Scripts/DamageSystem.cs:52\n at Clinicly.Game.Bullet.OnTriggerEnter (UnityEngine.Collider other) [0x0001a] in /Assets/Scripts/Bullet.cs:41\n\nMissingReferenceException: The object of type 'Transform' has been destroyed but you are still trying to access it.\n at UnityEngine.Transform.get_position ()\n at Clinicly.Game.HomingBullet.FixedUpdate () [0x00010] in /Assets/Scripts/HomingBullet.cs:33\n\n480 users, all on the wave-12 boss", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "detekt and the runtime disagree about this coroutine scope, and users see duplicate bookings:\n\nclass BookingViewModel(\n private val repo: AppointmentRepository,\n private val scope: CoroutineScope = CoroutineScope(SupervisorJob() + Dispatchers.Default)\n) : ViewModel() {\n\n fun book(slotId: String) {\n scope.launch {\n val result = repo.book(slotId)\n _state.update { it.copy(booked = result) }\n }\n }\n\n override fun onCleared() {\n super.onCleared()\n }\n}\n\ntapping book twice quickly creates two appointments about 30% of the time, and rotating the phone mid-book does it every time", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "security questionnaire from a hospital customer came back with this section and i need to answer honestly:\n\n7.3 — Does the application enforce role-based access control at the API layer, and are authorization decisions logged?\n7.4 — Are patient records segregated per tenant at the database level, and if so by what mechanism?\n7.5 — Describe session invalidation on password change and on administrative account suspension.\n7.6 — Are audit logs immutable and retained for at least six years?\n7.9 — Can a clinic administrator export all data for a single patient on request, and how long does that take?\n\ngo through our rails app and tell me what's actually true for each of these", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "someone's proposed this ECS refactor in the game repo and i can't tell if it's an improvement or just fashion:\n\n// current\npublic class Enemy : MonoBehaviour {\n public float speed; public int hp;\n void Update() { transform.position += dir * speed * Time.deltaTime; }\n}\n\n// proposed\npublic struct Position : IComponentData { public float3 Value; }\npublic struct Velocity : IComponentData { public float3 Value; }\npublic partial struct MoveSystem : ISystem {\n public void OnUpdate(ref SystemState state) {\n foreach (var (pos, vel) in SystemAPI.Query<RefRW<Position>, RefRO<Velocity>>())\n pos.ValueRW.Value += vel.ValueRO.Value * SystemAPI.Time.DeltaTime;\n }\n}\n\nwe have maybe 300 enemies on screen at peak and a two-person team", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility audit output for the booking flow, tell me which of these are real problems and which are the tool being pedantic:\n\nsrc/booking/SlotPicker.tsx\n serious Buttons must have discernible text (button-name) — 14 nodes\n serious Form elements must have labels (label) — 3 nodes\n moderate Elements must have sufficient color contrast (color-contrast) — 22 nodes (4.1:1 vs required 4.5:1)\n minor Heading levels should only increase by one (heading-order) — 2 nodes\n\nsrc/booking/Confirmation.tsx\n critical <html> element must have a lang attribute (html-has-lang)\n serious ARIA attributes must conform to valid values (aria-valid-attr-value) — aria-live=\"polite \" (trailing space)\n moderate Interactive controls must not be nested (nested-interactive) — 1 node\n\n47 total violations, 0 incomplete", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "here's the query the scheduling page runs every time someone changes the week. is 400ms reasonable for this or is something dumb happening?\n\nSELECT a.id, a.starts_at, a.ends_at, a.status,\n p.first_name, p.last_name, p.date_of_birth,\n pr.display_name AS provider_name,\n r.name AS room_name,\n (SELECT COUNT(*) FROM appointment_notes n WHERE n.appointment_id = a.id) AS note_count\nFROM appointments a\nJOIN patients p ON p.id = a.patient_id\nJOIN providers pr ON pr.id = a.provider_id\nLEFT JOIN rooms r ON r.id = a.room_id\nWHERE a.clinic_id = $1\n AND a.starts_at >= $2 AND a.starts_at < $3\n AND a.status <> 'cancelled'\nORDER BY a.starts_at ASC;\n\nindexes: appointments(clinic_id, starts_at), patients(id), providers(id)", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "two engineers wrote the same helper in the same sprint. which one would you keep, and why?\n\n// version A — utils/time.ts\nexport function slotsBetween(open: Date, close: Date, minutes: number): Date[] {\n const out: Date[] = []\n for (let t = open.getTime(); t + minutes * 60000 <= close.getTime(); t += minutes * 60000)\n out.push(new Date(t))\n return out\n}\n\n// version B — booking/slots.ts\nexport const buildSlots = ({ open, close, step, skip = [] }: SlotArgs) =>\n Array.from(\n { length: Math.floor((+close - +open) / (step * 60000)) },\n (_, i) => new Date(+open + i * step * 60000)\n ).filter(d => !skip.some(([s, e]) => d >= s && d < e))\n\nboth are used in production right now, on different screens", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "raw notes from the clinic onboarding call, turn them into the implementation guide we hand to new customers:\n\n- they get a CSV of patients from their old system, columns never match, we map by hand today\n- provider availability set up in the admin, but recurring blocks (lunch, admin time) are a separate screen nobody finds\n- rooms are optional; single-provider clinics skip them entirely\n- SMS reminders need their own twilio number, takes 2-3 days for approval, has to start before go-live\n- test appointment then a test reminder is how we prove it works\n- go-live is always a monday, they keep the old system read-only for a month\n- most common failure: nobody set the clinic timezone and every reminder goes out an hour off", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "api reference for the availability endpoint is one sentence long. here's the controller — write the real thing:\n\ndef index\n clinic = Clinic.find(params[:clinic_id])\n authorize! :read, clinic\n range = DateRange.parse!(params[:from], params[:to])\n raise TooWide if range.days > 62\n providers = clinic.providers.where(id: params[:provider_ids].presence || clinic.provider_ids)\n slots = Appointments::Availability.new(clinic:, providers:, range:, duration: params.fetch(:duration, 30).to_i).build\n render json: { data: slots.map { |s| SlotSerializer.new(s) }, meta: { timezone: clinic.timezone } }\nend\n\ncover the 30-day default, the 62-day cap, what duration does, and that all times come back in clinic-local ISO8601", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "escreve o texto do post-mortem a partir destas notas, formato: impacto, cronologia, causa, ações:\n\n14:02 — clientes reportam que a agenda aparece vazia\n14:06 — on-call confirma: API devolve 200 com lista vazia para clínicas com fuso -03\n14:11 — deploy das 13:40 identificado como suspeito (mudança no cálculo de intervalos)\n14:19 — rollback iniciado\n14:26 — rollback concluído, agendas voltam ao normal\n14:40 — confirmado: 61 clínicas afetadas durante 24 minutos, nenhuma consulta perdida\n15:10 — causa: o novo cálculo usava a data do servidor em UTC em vez do fuso da clínica\n\nações combinadas: teste de regressão com fusos negativos, alerta para respostas vazias acima de 5%", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "pt"}
{"prompt": "kotlin file has zero kdoc and the next person will hate us. document the public surface based on what it does:\n\nclass SyncCoordinator(\n private val api: ApiClient,\n private val dao: AppointmentDao,\n private val clock: Clock,\n) {\n suspend fun pull(since: Instant?): SyncResult { /* ... */ }\n suspend fun push(pending: List<PendingEdit>): SyncResult { /* ... */ }\n suspend fun awaitIdle(timeout: Duration = 30.seconds)\n fun observeState(): Flow<SyncState>\n val lastSuccessfulSync: Instant?\n}\n\nthings worth capturing: pull with a null `since` does a full refresh and can take minutes on a big clinic; push is all-or-nothing per batch; awaitIdle throws on timeout; observeState never completes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "i have to explain our offline behaviour to the app review team and to our own support staff. here's what the code does, in bullets, from my reading:\n\n- edits made offline go into a `pending_edits` room table with a local revision\n- on reconnect, push happens before pull, oldest first\n- a 409 from the server means the server version won, and the local edit is discarded silently\n- appointments created offline get a client-generated UUID that the server honours\n- if the app is killed mid-sync, the worker restarts the whole batch\n- there is no user-visible indication that a local edit was discarded\n\nturn that into two documents: one for the app review notes, one for support", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "README for the game repo hasn't been touched since the jam version. current state of things:\n\n- unity 6000.0.28f1, URP, addressables for the level packs\n- three scenes that matter: Boot, Hub, Run. everything else is test scaffolding\n- input via the new Input System, bindings in Assets/Settings/PlayerControls.inputactions\n- steam build via a bash script in tools/, needs SteamCMD on PATH and a `.env` with the app id\n- tests: EditMode only, playmode tests are broken and skipped in CI\n- known: opening Run directly from the editor bypasses save loading and softlocks after the first wave\n\nwrite it so a new contributor can get to a running build without asking anyone", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "ktlint is blocking the merge, all of it looks cosmetic:\n\napp/src/main/java/io/clinicly/ui/ScheduleScreen.kt:41:1: Wildcard import (cannot be auto-corrected)\napp/src/main/java/io/clinicly/ui/ScheduleScreen.kt:88:121: Exceeded max line length (120)\napp/src/main/java/io/clinicly/ui/ScheduleScreen.kt:141:5: Missing newline before \"}\"\napp/src/main/java/io/clinicly/data/SyncCoordinator.kt:19:1: Package name must not contain underscore\napp/src/main/java/io/clinicly/data/SyncCoordinator.kt:66:33: Unnecessary semicolon\napp/src/main/java/io/clinicly/di/AppModule.kt:12:1: Imports must be ordered in lexicographic order\n\n> Task :app:ktlintMainSourceSetCheck FAILED\n6 style violations", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "pasted-context", "lang": "en"}
{"prompt": "rubocop after the rebase, just get it green:\n\nOffenses:\n\napp/services/appointments/availability.rb:14:5: C: Metrics/MethodLength: Method has too many lines. [22/15]\napp/services/appointments/availability.rb:41:81: C: Layout/LineLength: Line is too long. [104/100]\napp/services/appointments/reschedule.rb:9:3: C: Style/Documentation: Missing top-level class documentation comment.\napp/models/clinic_hours.rb:33:11: W: Lint/UselessAssignment: Useless assignment to variable - `tz`.\napp/controllers/api/v2/availability_controller.rb:22:7: C: Style/GuardClause: Use a guard clause instead of wrapping the code inside a conditional expression.\nspec/factories/appointments.rb:5:1: C: Naming/VariableNumber: Use normalcase for symbol numbers.\n\n612 files inspected, 6 offenses detected, 3 offenses auto-correctable", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependency check flagged these in the rails app, pick the ones we should just bump today:\n\nName: nokogiri\nVersion: 1.16.2\nAdvisory: CVE-2026-11221\nCriticality: High\nSolution: upgrade to '>= 1.17.1'\n\nName: rack\nVersion: 3.0.9\nAdvisory: CVE-2026-10884\nCriticality: Medium\nTitle: Possible ReDoS in Rack::Request header parsing\nSolution: upgrade to '>= 3.0.11'\n\nName: image_processing\nVersion: 1.12.2\nAdvisory: GHSA-7x2f-9k1c\nCriticality: Low\nSolution: upgrade to '>= 1.13.0'\n\nVulnerabilities found!", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "tsc is unhappy after the react 19 bump, and i think these are all the same mistake repeated:\n\nsrc/booking/SlotPicker.tsx:44:7 - error TS2322: Type '{ children: Element; ref: MutableRefObject<HTMLDivElement | null>; }' is not assignable to type 'IntrinsicAttributes & SlotGridProps'.\n Property 'ref' does not exist on type 'IntrinsicAttributes & SlotGridProps'.\n\nsrc/booking/Confirmation.tsx:19:23 - error TS2769: No overload matches this call.\n Argument of type '(e: React.FormEvent) => Promise<void>' is not assignable to parameter of type 'FormEventHandler<HTMLFormElement>'.\n\nsrc/schedule/WeekGrid.tsx:88:11 - error TS2339: Property 'defaultProps' does not exist on type 'FunctionComponent<WeekGridProps>'.\n\nFound 3 errors in 3 files.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "a short note for the team explaining why we moved reminders off after_commit, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "our repository interfaces return `Result<T>` in some places and throw in others; pick one and apply it, no behaviour change at the UI layer", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "the usual pre-release pass, you know the drill", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "appointment types are hardcoded as an enum in three languages: a rails enum, a kotlin sealed class, and a typescript union that's already out of date. how would you like to see this owned in one place? tell me the approach and then do the rails side", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "we keep telling customers that appointment data syncs \"in near real time\" and i genuinely don't know if that's true anymore given the worker changes. read the sync path, work out what the actual guarantees are — latency, ordering, what happens on conflict — and write the honest version for the docs site, including the caveats we'd rather not advertise", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "a migration note for integrators about the v2 availability response shape, they need to know about the `meta.timezone` field", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "our CI runs the android lint task twice, once in the check job and once in the release job, drop one", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "the compose theme file came from a contractor and i've been told it's \"basically standard\" three times by people who haven't opened it. i'd like an actual assessment against how material 3 expects to be set up, particularly the dynamic colour branch and the status bar side effect, before i add a dark palette on top of it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "we owe the partner an eligibility-check endpoint on our side by the end of the month: they call us with a patient reference and a payer id, we look up the patient, hit their sandbox, cache the answer for an hour, and return a normalised status. rate limit is 5 rps on their side and they penalise us for exceeding it", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "appointment durations over 4 hours render as a block with no end time, clamp it or show the end explicitly", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "config drift between the two staging clinics, one of them sends reminders at the wrong hour:\n\n# clinic 4412 (settings.yml)\nreminder_lead_hours: 24\nreminder_send_window: \"08:00-20:00\"\ntimezone: \"America/Santiago\"\nsms_enabled: true\nemail_enabled: true\nwaitlist_offer_window_minutes: 120\ndouble_booking_allowed: false\nslot_minutes: 30\n\n# clinic 4419 (settings.yml)\nreminder_lead_hours: 24\nreminder_send_window: \"08:00-20:00\"\ntimezone: \"UTC\"\nsms_enabled: true\nemail_enabled: false\nwaitlist_offer_window_minutes: 120\ndouble_booking_allowed: false\nslot_minutes: 15\n\n# production template both were cloned from\nreminder_lead_hours: 24\nreminder_send_window: \"08:00-20:00\"\ntimezone: null # must be set per clinic on creation\nsms_enabled: true\nemail_enabled: true\nwaitlist_offer_window_minutes: 120\ndouble_booking_allowed: false\nslot_minutes: 30\n\nboth were meant to be copies of that template and neither matches it", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "unity throws this every time the level loads and it's just noise in the console but it's hiding real errors:\n\nAssets/Scripts/UI/HUDController.cs(41,17): warning CS0618: 'Object.FindObjectOfType<T>()' is obsolete: 'Object.FindObjectOfType has been deprecated. Use Object.FindFirstObjectByType instead or if finding any instance is acceptable the faster Object.FindAnyObjectByType'\nAssets/Scripts/WaveDirector.cs(88,9): warning CS0618: same\nAssets/Scripts/Audio/MusicManager.cs(22,13): warning CS0618: same\nAssets/Scripts/Save/SaveSystem.cs(112,21): warning CS0672: 'SaveSystem.Serialize(Stream)' overrides obsolete member\n\n41 warnings total, 12 of them this one", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "esta función se repite en tres pantallas casi igual. quiero una sola versión, sin cambiar el comportamiento:\n\n// SlotPicker.tsx\nconst isBookable = (s: Slot) =>\n !s.taken && s.startsAt > new Date() && !s.blocked && s.providerId === selectedProvider\n\n// WeekGrid.tsx\nfunction bookable(slot) {\n if (slot.taken) return false\n if (slot.blocked) return false\n if (new Date(slot.startsAt) <= new Date()) return false\n return !provider || slot.providerId === provider\n}\n\n// WaitlistSheet.tsx\nconst canOffer = (slot: Slot, providerId?: string) =>\n [!slot.taken, !slot.blocked, +new Date(slot.startsAt) > Date.now(),\n providerId ? slot.providerId === providerId : true].every(Boolean)", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "es"}
{"prompt": "this composable has grown a fifth responsibility and i want it split without changing a pixel:\n\n@Composable\nfun ScheduleScreen(vm: ScheduleViewModel = hiltViewModel()) {\n val state by vm.state.collectAsStateWithLifecycle()\n val snackbar = remember { SnackbarHostState() }\n LaunchedEffect(state.error) { state.error?.let { snackbar.showSnackbar(it) } }\n LaunchedEffect(Unit) { vm.trackScreenView() }\n Scaffold(\n topBar = { /* 40 lines of week picker, provider filter and overflow menu */ },\n snackbarHost = { SnackbarHost(snackbar) },\n floatingActionButton = { /* 20 lines with three conditional states */ },\n ) { padding ->\n when {\n state.loading -> ShimmerGrid(padding)\n state.days.isEmpty() -> EmptyDay(padding, onRefresh = vm::refresh)\n else -> /* 90 lines of day columns, drag-to-reschedule and overlap layout */\n }\n }\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "service object that grew organically. same behaviour, better seams, and it needs to stay callable from the controller exactly as it is:\n\nclass Appointments::Reschedule\n def initialize(appointment, new_slot, actor:, notify: true, skip_validation: false)\n @appointment = appointment; @new_slot = new_slot; @actor = actor\n @notify = notify; @skip_validation = skip_validation\n end\n\n def call\n raise OutsideClinicHours unless @skip_validation || within_hours?\n raise SlotTaken if Appointment.overlapping(@appointment.clinic_id, @new_slot.range).where.not(id: @appointment.id).exists?\n ActiveRecord::Base.transaction do\n @appointment.update!(starts_at: @new_slot.starts_at, ends_at: @new_slot.ends_at)\n AuditLog.create!(actor: @actor, action: \"reschedule\", subject: @appointment)\n CalendarSyncJob.perform_later(@appointment.id)\n PatientMailer.rescheduled(@appointment).deliver_later if @notify\n SmsSender.new(@appointment.patient).rescheduled(@appointment) if @notify && sms?\n end\n @appointment\n end\nend", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "four scripts in the unity project all reach for the player the same way. i want one accessor and no behaviour change:\n\n// WaveDirector.cs\nvar player = GameObject.FindWithTag(\"Player\").GetComponent<PlayerController>();\n\n// HomingBullet.cs\nvar player = GameObject.Find(\"Player\").transform;\n\n// HUDController.cs\nPlayerController player = FindObjectOfType<PlayerController>();\n\n// SaveSystem.cs\nvar player = GameObject.FindGameObjectsWithTag(\"Player\").FirstOrDefault()?.GetComponent<PlayerController>();\n\nall four are called from Update or from OnEnable, some of them every frame", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "test suite has this shape repeated 60-odd times and it's why nobody adds tests:\n\nRSpec.describe Appointments::Availability do\n let(:clinic) { create(:clinic, timezone: \"America/New_York\") }\n let(:provider) { create(:provider, clinic: clinic) }\n let!(:hours) { create(:clinic_hours, clinic: clinic, weekday: 1, opens_at: \"09:00\", closes_at: \"17:00\") }\n let(:range) { Date.new(2026, 8, 3)..Date.new(2026, 8, 3) }\n\n before do\n travel_to Time.zone.parse(\"2026-08-01 08:00\")\n allow(FeatureFlags).to receive(:enabled?).with(:waitlist).and_return(false)\n end\n\n after { travel_back }\n # ... 8 examples\nend\n\nsame five let blocks, same travel_to, same flag stub, in every scheduling spec", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "navigation in the app is half compose-navigation and half fragments, this is the current graph plus the leftovers:\n\nNavHost(navController, startDestination = \"schedule\") {\n composable(\"schedule\") { ScheduleScreen() }\n composable(\"booking/{slotId}\") { BookingScreen(it.arguments?.getString(\"slotId\")!!) }\n composable(\"patient/{id}\") { PatientScreen(it.arguments?.getString(\"id\")!!) }\n activity(\"legacy_settings\") { activityClass = SettingsActivity::class }\n}\n\n// still around\nclass PatientListFragment : Fragment() // reached from SettingsActivity\nclass ProviderPickerFragment : DialogFragment() // shown from ScheduleScreen via FragmentManager\nclass OnboardingActivity : AppCompatActivity() // launched from MainActivity.onCreate\n\nthe hybrid is why back handling is inconsistent. same destinations, one mechanism", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "un fichier de constantes qui a mal vieilli, je veux le réorganiser sans rien casser :\n\n// constants.ts\nexport const SLOT_MINUTES = 30\nexport const MAX_RANGE_DAYS = 62\nexport const API_BASE = process.env.NEXT_PUBLIC_API ?? \"https://api.clinicly.io\"\nexport const COLORS = { booked: \"#2f6fed\", blocked: \"#9aa0a6\", free: \"#ffffff\" }\nexport const REMINDER_LEAD_HOURS = 24\nexport const WAITLIST_WINDOW_MIN = 120\nexport const FEATURE_WAITLIST = true\nexport const DATE_FMT = \"yyyy-MM-dd\"\nexport const TZ_FALLBACK = \"UTC\"\nexport const SUPPORT_EMAIL = \"[email protected]\"\nexport const RETRY_DELAYS = [1000, 2000, 4000, 8000]\nexport const LEGACY_SLOT_MINUTES = 15 // still used by the old week grid\n\nimporté par 41 fichiers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "fr"}
{"prompt": "discovery notes from the clinic visits last week. i need this turned into a roadmap with phases, not a feature list:\n\n- front desk staff use paper for the waitlist because the digital one takes too many taps\n- three of five clinics double-book deliberately for no-show buffer; our model forbids it\n- providers want to see their own day on a phone, receptionists want the whole clinic on a monitor\n- nobody uses the reporting screen; two clinics export to excel weekly instead\n- the biggest complaint is that cancelling requires four confirmations\n- one clinic runs two locations from one account and it half-works\n- insurance eligibility check is done outside our system entirely, on a separate portal", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "leadership handed down this constraint set for the mobile rewrite and i need a realistic sequencing before we commit to dates:\n\n- android and ios must ship the same features at the same time from Q4\n- the current android app is kotlin/compose, ios is a webview wrapper nobody maintains\n- team is four android engineers, one ios contractor starting in september\n- offline support is non-negotiable for both, clinics have bad wifi\n- the design system exists in figma but only android components are built\n- there is a hard deadline: a customer conference in march where both must demo\n- we cannot stop shipping android features in the meantime", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "game's save system is about to become a problem and i'd rather design now than patch later. current state:\n\n- SaveSystem.cs writes a JSON blob to Application.persistentDataPath every checkpoint\n- no versioning; loading an old save from before the wave rework silently zeroes progress\n- cloud saves via steam are on the roadmap for the 1.0 release\n- players have already reported losing runs when the game is force-quit mid-write\n- we want a run history screen eventually, which means multiple saves, not one blob\n\nwhat should the shape of this be, and what's the migration path for saves already in the wild", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "compliance ticket landed and i don't want to start coding before we agree the shape:\n\nCOMP-118 — Audit trail for patient record access\nEvery read of a patient record must be recorded: who, when, which record, from which client, and the stated reason where one is required. Records must be queryable by patient (for subject access requests) and by user (for internal investigations). Retention six years, tamper-evident. Must not measurably slow the schedule screen, which reads dozens of patient summaries per page load. Applies to API, admin panel and the mobile apps. Existing access is not backfilled.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "figma redlines for the new day column, build it in compose:\n\nDay column (phone, 360dp)\n- Header: weekday abbrev (labelMedium) over day number (headlineSmall). Today: number in a 32dp filled circle, onPrimary text.\n- Hour rows 64dp tall, 1dp divider at 12% onSurface. Half-hour: dotted divider, 6% opacity.\n- Appointment block: 8dp corner, 4dp inset from the column edges, 3dp leading accent bar coloured by appointment type. Title bodyMedium truncated to one line; patient name bodySmall, 70% alpha.\n- Overlaps: split the column evenly, 2dp gutter, max three side by side, then \"+N\" chip on the third.\n- Now line: 2dp accent, dot at the leading edge, only shown for today.\n- Drag to reschedule: block lifts 4dp with shadow, snaps to 15-minute steps, target row highlighted at 8% accent.\n- Empty state: centred \"Nothing booked\" bodyMedium at 50% alpha.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ticket with the designer's notes attached, the waitlist sheet on web:\n\nWaitlist sheet (desktop modal, 480px)\n- Title \"Join the waitlist\" (20px semibold), subtitle with the chosen day in long form.\n- Provider select: our existing Select component, defaults to \"Any provider\", shows avatars.\n- Time-of-day preference: three toggle chips (Morning / Afternoon / Any), single select, \"Any\" default.\n- Contact preference: radio group, SMS / Email, prefilled from the patient record, with the masked contact shown next to each.\n- Footnote in 12px muted: \"We'll hold your spot for 2 hours once we offer it.\"\n- Primary \"Join waitlist\", secondary \"Cancel\". Primary disabled while submitting, spinner inside the button.\n- On success the modal is replaced in place by a confirmation state with a checkmark, no navigation.\n- Errors render above the buttons in a red inline alert, never a toast.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "这是设计稿标注，帮我把预约确认页写出来（React + Tailwind）：\n\n确认页（移动端 375px）\n- 顶部：诊所名称 16px 中等字重，下面是地址 13px 灰色，右侧是地图图标按钮 40x40。\n- 主卡片：圆角 12px，1px 边框，内边距 16px。第一行日期 20px 半粗，第二行时间段 15px。\n- 医生一行：32px 头像 + 姓名 + 科室，中间用 8px 间距。\n- 提醒开关：默认开启，副标题写「就诊前 24 小时短信提醒」。\n- 底部按钮：主按钮「确认预约」占满宽度 48px 高，次要按钮「取消」文字按钮。\n- 加载中：主按钮内显示 spinner，其余内容保持不动。\n- 出错时在按钮上方显示红色提示条，不要弹窗。", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "zh"}
{"prompt": "spec from the integration partner, build our side of it:\n\nPOST /v2/webhooks/eligibility\n headers: X-Partner-Signature (HMAC-SHA256 of the raw body, secret per partner), X-Partner-Id\n body: { request_id, patient_ref, payer_id, status: \"active\"|\"inactive\"|\"unknown\", copay_cents?, checked_at }\n we must respond 200 within 3 seconds or they retry with the same request_id for 24 hours\n duplicate request_id must be a no-op that still returns 200\n unknown patient_ref: respond 200 and record it, do not 404 (they treat 4xx as a hard failure and disable the hook)\n signature mismatch: 401, and we should alert\n they send roughly 40k of these a day, bursty around 06:00 clinic-local", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "reminder lead time to 48h", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "versionCode wasn't bumped for the hotfix", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "\"appointement\" in the confirmation email", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "proguard rule for the analytics SDK", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "strip the debug toast from BookingScreen", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "en"}
{"prompt": "sentry DSN is still the staging one", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "delete the dead `LEGACY_SLOT_MINUTES`", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "el copy del botón dice «Reservar», debería ser «Confirmar»", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "es"}
{"prompt": "nokogiri to 1.17.1 please", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "turn off dynamicColor for now", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "today's date needs a filled circle", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "pull-to-refresh on the day view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "provider avatars in the week header", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "minimap clips on ultrawide", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "empty day needs an illustration", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "ボタンのタップ領域が小さすぎます", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "ja"}
{"prompt": "cancel confirmation should be one tap", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "slot chips wrap badly at 320dp", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "now-line should be accent, not red", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "HUD scale is wrong on deck", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "`ApptSvc` should read `AppointmentService`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "lift the week picker out of ScheduleScreen", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "die Konstanten nach Bereichen gruppieren", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "de"}
{"prompt": "a nightly job that flags appointments whose provider no longer works at the clinic, so front desk can reassign them before the patient turns up", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "our staging data is a six-month-old production dump with names scrambled, which is why timezone bugs never show up before release. what should the test data story actually be", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "the changelog for the android app has been \"bug fixes and improvements\" for six releases, which is embarrassing given how much has actually changed. go through the commits since 3.0, write proper release notes for each version, and while you're in there fix the two entries in the existing changelog that describe features we cut", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.4, "slice": "mixed", "lang": "en"}
{"prompt": "collapse the two slot builders", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "`starts_at` naming, consistent everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "shared rspec context for scheduling specs", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "one player accessor for all scripts", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "inline `bookable`, it's used once", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "play store release notes, friendly tone", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "changelog entry for the waitlist", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "kurze Doku für den Reminder-Job", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
{"prompt": "summarise `Availability#build` for the wiki", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the ANR fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "where does `skip_validation` come from?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "¿qué hace exactamente `SyncCoordinator.pull`?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "es"}
{"prompt": "which of these two helpers is safer?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the offer job", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "any reason `after_commit` fires twice here?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "reminders went out an hour early", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "week view flickers on day change", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "booking twice creates two appointments", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "le calendrier reste vide après le login", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "fr"}
{"prompt": "soft-delete on appointments, rails side", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "plan the audit trail, then build phase one", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "scope the ios rewrite, then start the shell", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "same as yesterday", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "clean this up", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "go ahead with the waitlist", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "nicer", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "onboarding, but properly this time", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "weiter wie besprochen", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "de"}
{"prompt": "you know what to do", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "できるところまでお願いします", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "ja"}
{"prompt": "round two on the sync", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "make the wave feel meaner", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "do the needful on scheduling", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidy the theme file", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "o de sempre, mas para a agenda", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "pt"}
{"prompt": "clinics with two locations are running on one account and it half works today: shared provider list, shared patient records, but the schedule screen can only show one location's rooms at a time and reminders always use the first location's address. before we build multi-location properly i want to know whether that's a data model change or a permissions change, and what it does to every clinic already on the platform", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "insurance eligibility is checked on a separate portal today and front desk staff retype the result into a note. bringing it in-house means a partner API, PHI leaving our boundary in a new direction, and a support burden when the payer is down. i'd like the options laid out — full integration, deep link with prefill, or nothing — with what each costs us over a year", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "game needs a difficulty curve that isn't just hp multipliers and i keep going back and forth. we have wave composition, enemy stats, spawn rate, arena hazards and drop rates as knobs, plus a run-length target of about 25 minutes. sketch out how you'd structure the tuning so a designer can iterate without touching code, and what we'd need to log to know whether it's working", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "hospital group wants us on their infrastructure rather than our cloud, which we have never done. that means a deployment story, a licence story, an upgrade story and a support story, none of which exist. i want the shape of what we'd have to build and what we'd have to say no to, before sales promises anything in the next call", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "clinic staff turnover is high and every new receptionist gets trained by the last one, which is why nobody knows about half the features. i'd like a proper training guide: the daily workflow start to finish, the five things that go wrong most often and how to fix them, and a one-page cheat sheet they can print and stick on the monitor", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "android release process lives in one engineer's head: which branch, when to bump versionCode, the staged rollout percentages, when to promote, what to do when crashlytics spikes mid-rollout, and how to halt. write it down as a runbook that someone else could follow on a wednesday afternoon without asking them anything", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "steam page copy is three sentences and reads like a placeholder because it is one. the game is a roguelike with a clinic aesthetic, run-based, 25-minute runs, deck-of-treatments mechanic. write the store description, the short blurb, and the five bullet features, in a voice that isn't every other roguelike page", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "reading `Appointments::Availability` end to end took me an hour and i still couldn't tell you why the 62-day cap exists or what the `duration` parameter really does to slot boundaries. go through it and tell me what it does, where the surprises are, and which behaviours look intentional versus accidental", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "on-call docs claim the reminder job is idempotent and safe to re-run, and i want that verified rather than assumed before someone re-runs it during an incident at 3am. trace it properly: what it reads, what it writes, what happens if two copies run at once, and whether a patient could get two texts", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "schedule screen makes about forty network calls when you switch weeks quickly, one per day column, and half of them are cancelled mid-flight. the data layer is supposed to coalesce these. same behaviour on screen afterwards, but i want the fetching restructured so it's one request per week and cancellation is handled in one place", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "rails app has thirteen service objects under `app/services/appointments/` and four of them are wrappers around another one, which nobody can see without reading all thirteen. i'd like the layer flattened into something honest, same public entry points from the controllers, same behaviour, fewer indirections", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "every screen in the app builds its own retrofit call, its own loading boolean and its own error string, so the same three-state dance is written 20 times with subtle differences. i want one pattern applied everywhere without changing what any screen looks like or how it behaves offline", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "biggest source of paper cuts is that the confirmation modal, the sheet on mobile and the toast all render appointment times through different formatting helpers, so they disagree about am/pm and timezone suffixes. one helper, all three call sites, and the output should match the modal's current format", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "gradle config for the android app has accumulated flags from three years of stack overflow answers and nobody knows which are load-bearing. tidy it up, keep the build producing an identical APK, and tell me which flags you removed and why", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "before the multi-location work starts i want the current single-location assumptions written down — every place the code assumes one address, one timezone, one set of rooms — and then a phased plan for undoing them. the audit first, the plan second, both in one document if that reads better", "purpose": "planning", "secondary": "review", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "waitlist feature needs a design before code, but it also needs the offer expiry job soon or QA can't test anything. give me the design for the whole flow, then implement just the expiry worker against it so the rest can land behind it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "das Sync-Verhalten der App ist weder dokumentiert noch besonders durchdacht: Push vor Pull, Konflikte gewinnt immer der Server, verworfene Änderungen sieht der Nutzer nie. Ich hätte gern erst ein Konzept, wie es aussehen sollte, und danach die Umsetzung des Konfliktfalls im Repository", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "de"}
{"prompt": "nobody outside the team understands what the sync worker does, and the parts i understand look wrong. write the explainer for the rest of engineering, and while you're in there work out whether a discarded local edit can ever take a patient's cancellation with it", "purpose": "writing", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "support has asked for a page explaining why a reminder might not arrive, which needs to cover the timezone setting, the send window, the twilio number status and the do-not-disturb flag on the patient record. write that, and separately confirm from the code that those four are actually the only reasons", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "audit-trail schema we sketched last week never made it into the repo, and the ticket is now in this sprint. put the design into `docs/adr/` properly, then stand up the migration and the write path for API reads only — the admin panel can follow later", "purpose": "writing", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "`SyncCoordinator` and `AppointmentRepository` overlap so much that i can never remember which one owns the pending-edit queue. merge the responsibilities sensibly, and afterwards write the class-level docs so the boundary is obvious to whoever touches it next", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "there are two spawn systems in the unity project, the jam-era one and the new director, and both are wired into the boot scene. delete the dead one carefully, and note in the design doc which behaviours we deliberately dropped so the designers aren't surprised", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "scheduling API returns 200 with an empty array when a clinic's timezone is unset, which is how we shipped a 24-minute outage. work out every endpoint with that failure mode, then make them fail loudly instead", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "patient search is a plain LIKE query and takes two seconds on the bigger clinics. i want fuzzy matching on name and date of birth, with the exact matches ranked first", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "recurring provider blocks — lunch, admin time, theatre lists — need to exist as real records rather than one-off appointments, with an end date and the ability to skip a single occurrence", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "an internal endpoint that returns a clinic's next 30 days of capacity as a single payload, for the reporting screen. cache it for five minutes, key on clinic and provider filter", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "run summary screen at the end of a game — time survived, waves cleared, treatments used, a graph of damage over time, and a share button that copies a text summary", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "drag-to-reschedule on the web week grid, snapping to 15 minutes, with the original position ghosted while dragging", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "toast messages stack up and cover the FAB when sync retries, needs a proper snackbar host with a queue", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "boss health bar overlaps the wave banner at 21:9, and both are anchored to the top centre", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "what's the actual difference between `pull(null)` and `pull(lastSync)` in terms of what the server sends back", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "opinions on the `after_commit` calendar sync in the appointment model — is that going to bite us under load?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "is there anything in the waitlist offer flow that could offer the same slot to two patients at once", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "could someone explain the difference between our `Slot` and `Availability` models to me, they seem to overlap completely", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "someone needs to explain, in writing, what our appointment status transitions are — the code has six statuses and the docs mention four", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "give me a plain-english account of what the eligibility webhook handler does with a duplicate request id", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "how does the save system decide a run is finished — i can see two places that write the final state", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "docs/scheduling.md describes the availability algorithm from two rewrites ago, bring it in line with the code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "kdoc on our public data classes is copy-pasted from the field names and adds nothing, make it actually useful", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "`ClinicHours#slots_for` and `Availability#build` have grown into each other; separate the concerns without changing what the endpoint returns", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "pull the twilio and sendgrid calls behind one notification port so tests stop hitting HTTP stubs directly", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "enemy scripts each hold their own copy of the tuning numbers, move them to scriptable objects with the same values", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "rename the `booking` package to `appointments` across the android app, it's confused with the web team's `booking` for two years now", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "three components import `formatSlotTime` from three different files that all re-export the same function, collapse the chain", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "新しい医師を追加すると、既存の予約の色が全部変わってしまいます。色の割り当てを固定にできますか", "purpose": "quickFix", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.35, "slice": "mixed", "lang": "ja"}
{"prompt": "deep links from a reminder open the app but land on the schedule root instead of the appointment, and it's been like that since the navigation change", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we need a position on offline conflict resolution before the ios work starts, because copying android's silent server-wins would be a mistake to repeat twice", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "appointment reminders, waitlist offers and calendar sync all send messages, and each one built its own template handling. what would a single messaging layer look like here", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "whatever's next on the schedule board", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "mobile confirmation sheet shows only the time right now, which is useless when a patient has appointments at two of the clinic's sites. it needs the clinic name, the street address under it, a map button that opens the native maps app, and the provider's name — without making the sheet taller than the detent it opens at", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "setting up a dev environment here takes a full day because the instructions are spread across a wiki page, a pinned slack message and one engineer's memory. we need one document: prerequisites, the database seed step, how to point the app at the local API, how to get test twilio credentials, and the three things that always go wrong on a new mac", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "internally nobody can describe how appointment sync works without drawing on a whiteboard, so it gets explained badly and differently every time. one document, covering the pull path, the push path, what the revision numbers mean, when the worker gives up, and what the user sees at each stage — diagrams are welcome but the prose has to stand alone", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a patient who moved from Madrid to Mexico City still gets reminders on Spanish time as far as support can tell, and i want to know whether that's the code or the data. the reminder job reads the clinic timezone, not the patient's, so on paper it shouldn't matter — but the patient record has a timezone column that something must be using", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "sidekiq queue names drifted from the job class names over about two years, so `ReminderJob` runs on `default`, `CalendarSyncJob` runs on `mailers` of all things, and two jobs share a queue that's meant to be low priority. line them up with the class names, keep the priority weights we have today, and don't leave jobs stranded on the old queues during the deploy", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "providers keep asking for a view that's just their own day: their appointments only, defaulting to today, remembering the last provider they picked between launches, and usable one-handed while walking between rooms. it should open instantly from the local cache and refresh quietly behind that, with no spinner unless there's genuinely nothing cached", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "reporting is the screen clinics complain about most and also the one we understand least — five joins per row, no aggregates, and now they want twelve-month ranges. work out what it's really doing today and where the time goes, then propose whether we need a read model, a materialised view, or just better indexes. i want the analysis and the recommendation, not an implementation", "purpose": "planning", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "compose multiplatform versus two native codebases is the decision blocking our ios plan, and i'd rather see it reasoned through than argued about in standup. weigh it for our situation — four android engineers, one ios contractor, offline-first requirements, a design system that only exists for android — then draft the ADR whichever way it lands", "purpose": "planning", "secondary": "writing", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "bookings made close to midnight land on the wrong day for the provider but the right day for the patient, at least in Chile and probably anywhere with a negative offset. find out where the date gets derived from the wrong clock, and once you know, add the regression tests that would have caught it — parameterised over a few nasty timezones", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like someone to read the eligibility webhook handler with fresh eyes — signature check, replay handling, what happens when the patient reference is unknown — and tell me whether it matches the partner's spec. if the retry behaviour is as wrong as i suspect, fix the handler as part of the same pass", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "our appointment status transitions are documented as four states and implemented as six, and support has built workarounds around the undocumented ones. work out what the real state machine is from the code, then write the reference page that we should have had, flagging any transition that looks accidental", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "`app/services/appointments/` has thirteen classes where four would do, and half of them are one-line wrappers. consolidate the layer so the controllers call the same entry points they call today, then update the service-layer section of the architecture doc, which describes a structure we abandoned last year", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "the slot picker fails almost every accessibility check we run — no content descriptions on the chips, 32dp touch targets, and a focus order that jumps between columns. bring it up to standard, and take a screenshot pass afterwards so i can put the before and after in the procurement questionnaire", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt":"Incident timeline — INC-42142\n\n08:02 deploy BorealNimbusFormFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current BorealNimbusFormFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a BorealFlintTimelineService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Before we approve BorealGarnetModalStore, assess whether lost focus when the drawer animation finishes is an actual correctness risk or merely confusing structure. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"PM needs a concise migration note for BorealOpalRouterService, including the user impact, rollback trigger, and the one configuration key operators must change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealBirchMigratorCoordinator: handle the lingering thing","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Set BorealSlateEditorService's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Opal: # projects/boreal/services/ledger/replay.go\n[worker.borealravensessionflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealravensessionflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealravensessionflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealRavenSessionFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42143\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nThe intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/boreal/services/ledger/replay.go and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Release verification found a single stale BorealIrisBatchService value; the cause, desired value, and affected assertion are already agreed. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Kafka operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Dedupe BorealOrbitSyncService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Documente le contrat BorealRainfallDBStore","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"Why does BorealLumenChartService's Kafka worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Give BorealCraneWorkspaceService a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Prism: // projects/boreal/Sources/App/SessionStore.swift\nfinal class BorealFrostPanelFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate BorealFrostPanelFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealSummitProxyService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Cloudflare Workers operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Quartz: // projects/boreal/crates/index/src/segment.rs\nfinal class BorealJuniperCLIFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nWalk through what the artifact proves about BorealJuniperCLIFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealFlintTimelineCoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-42115: retire the legacy replay path for BorealBeaconStoreFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current BorealBeaconStoreFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealJuniperCLICoordinator needs a paired pass: produce a consumer guide for BorealJuniperCLICoordinator, plus correct the known stale timeout beside it. Use projects/boreal/pkg/cache/lease.rs as the source of truth, preserve the Cloudflare Workers contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Raven: Incident timeline — INC-42136\n\n08:02 deploy BorealOspreyJobFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the BorealOspreyJobFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealQuartzPlayerCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"BorealMicaProfileCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Sable: Release verification found a single stale BorealAmberFilterStore value; the cause, desired value, and affected assertion are already agreed. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Kotlin coroutines operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'BorealEchoRegistryCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealEchoRegistryCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/web/components/FilterDrawer.vue:144: error: -[BorealEchoRegistryCoordinatorTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[BorealEchoRegistryCoordinatorTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Use the UI evidence to complete BorealEchoRegistryCoordinator's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Introduce a durable deduplication key for BorealNimbusFormService events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Tide: projects/boreal/engine/render/atlas.cpp now contains BorealWillowCodecStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Umbra: Incident timeline — INC-42140\n\n08:02 deploy BorealGarnetModalFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the material above into a concise BorealGarnetModalFlow release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Give BorealMoonlitSDKStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'BorealKiteSchedulerCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealKiteSchedulerCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/db/migrations/20260730_events.sql:144: error: -[BorealKiteSchedulerCoordinatorTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[BorealKiteSchedulerCoordinatorTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nReconstruct the BorealKiteSchedulerCoordinator failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Vela: The destination for BorealWrenExportStore is broadly agreed; the missing piece is a reversible route from projects/boreal/workers/thumbnail/consumer.ex to that target. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealWrenExportStore\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind BorealDriftConsoleStore's Cloudflare Workers choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Walk through BorealFernSnapshotStore's atlas.cpp","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Compare the old and new BorealSpruceDaemonStore adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind BorealCinderAuthStore's GraphQL choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-42157: retire the legacy replay path for BorealVelaDrawerCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current BorealVelaDrawerCoordinator behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/boreal/ml/pipeline/features.py b/projects/boreal/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/ml/pipeline/features.py\n+++ b/projects/boreal/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate BorealNovaPickerFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"A previously stable test around BorealBirchMigratorService now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Dokumentiere BorealQuartzPlayerStore kurz","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"de"}
{"prompt":"For BorealHarborIndexCoordinator, separate BorealHarborIndexCoordinator's policy from transport without behavior changes; once that is complete, capture the contract and rollback note for consumers. Work from projects/boreal/internal/auth/refresh.go, stay with Kotlin coroutines, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Is BorealBeaconStoreService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"On compact widths, BorealBasilRunnerFlow's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Two asks around BorealCedarPolicyCoordinator: (1) find the unknown cause of two validators with subtly different error strings; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"BorealSableParserService has four wrappers that only translate the same error enum. Collapse them into one adapter and preserve every public case, message, and metric label.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"projects/boreal/lib/codec/frame.cc has grown through several launches, and BorealIrisBatchStore now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to BorealIrisBatchStore and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"BorealSpruceDaemonCoordinator: could this be clearer","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealSableParserCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_42122'\n AND e.created_at >= now() - interval '24 hours'\nGROUP BY e.tenant_id, e.stream_id;\n\nHashAggregate (cost=184922.10..185011.81 rows=8971 width=40) (actual time=8421.294..8422.551 rows=123 loops=1)\n Group Key: e.tenant_id, e.stream_id\n Batches: 1 Memory Usage: 945kB\n -> Hash Join (cost=2118.42..181004.17 rows=522391 width=32) (actual time=42.118..8279.405 rows=918412 loops=1)\n Hash Cond: ((e.tenant_id = s.tenant_id) AND (e.stream_id = s.id))\n -> Bitmap Heap Scan on event_log e (actual time=18.602..7922.884 rows=1261044 loops=1)\n Recheck Cond: (tenant_id = 't_42122'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDetermine why BorealFernSnapshotFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealNimbusFormCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealAcornWidgetCoordinator: correct, then assess","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"BorealSlateEditorCoordinator: sequence, then polish","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealPrismCacheService's metric is misspelled as succesful_total in one declaration. Correct that literal and its exact test expectation, without renaming anything else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Move BorealSummitProxyFlow's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/boreal/db/migrations/20260730_events.sql, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"The BorealDeltaCanvasStore empty state in projects/boreal/config/staging.toml needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current BorealEmberRelayService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealEmberRelayService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"On compact widths, BorealCinderAuthService's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"BorealRainfallDBCoordinator needs a paired pass: separate BorealRainfallDBCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/boreal/ui/settings/PrivacyPane.tsx as the source of truth, preserve the Kafka contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current BorealDriftConsoleService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealDriftConsoleService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: BorealMarbleTokenService has one known configuration mistake in projects/boreal/infra/modules/edge/main.tf, not an open-ended failure investigation. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to BorealMarbleTokenService and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-42128\n\n08:02 deploy BorealHarborIndexFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the material above into a concise BorealHarborIndexFlow release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/boreal/cmd/exporter/main.py b/projects/boreal/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/cmd/exporter/main.py\n+++ b/projects/boreal/cmd/exporter/main.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure BorealPineMetricsFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"In projects/boreal/app/src/main/SyncWorker.kt hat BorealAtlasSearchService ein sporadisches Problem im GraphQL-Ablauf. Vervollständige Responsive Layout, Empty- und Retry-State, Tastaturfokus, Dark Mode und Reduced Motion.\n\nRandbedingungen:\n- GraphQL weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf BorealAtlasSearchService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um BorealAtlasSearchService mit GraphQL kompatibel.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"Split BorealAsterWebhookStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The name pendingAck means two different things across BorealMarbleTokenFlow's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"# projects/boreal/packages/api/openapi.yaml\n[worker.borealquartzplayerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealquartzplayerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealquartzplayerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealQuartzPlayerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42119\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nThe intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/boreal/packages/api/openapi.yaml and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Dedupe BorealFrostPanelStore's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Stream BorealFernSnapshotService's audit events","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Does BorealOspreyJobStore enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"PM needs a concise migration note for BorealFlintTimelineStore, including the user impact, rollback trigger, and the one configuration key operators must change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealOrbitSyncCoordinator is blocking the next release because cancellation being swallowed at the repository boundary. I need two concrete outcomes from a single pass: assess ownership and failure handling in projects/boreal/crates/index/src/segment.rs, and capture the contract and rollback note for consumers. Use the existing Cloudflare Workers conventions in projects/boreal/crates/index/src/segment.rs; leave generated files and vendored code alone. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-42114: retire the legacy replay path for BorealOrbitSyncFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess BorealOrbitSyncFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealOspreyJobCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new BorealVelaDrawerStore adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Remove BorealFrostPanelService's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"BorealGarnetModalCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Willow: The BorealMicaProfileStore surface in projects/boreal/ml/pipeline/features.py is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Xylem: projects/boreal/web/components/FilterDrawer.vue 里的 BorealRavenSessionStore 最近在 Kotlin coroutines 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 Kotlin coroutines\n- 保持兼容性和取消语义\n- 改动只限于 BorealRavenSessionStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Two deliverables are holding up BorealBeaconStoreCoordinator. First, finish BorealBeaconStoreCoordinator's responsive empty and retry states. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/boreal/cmd/exporter/main.py, which follows Spring Boot conventions and currently suffers from a feature flag whose default differs between environments. Leave generated files and vendored code alone.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Yarrow: Two asks around BorealCraneWorkspaceCoordinator: (1) change BorealCraneWorkspaceCoordinator's known staging timeout from 15 to 30 seconds; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Zephyr: Ticket OPS-42151: retire the legacy replay path for BorealEmberRelayCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current BorealEmberRelayCoordinator behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Where did BorealHarborIndexService's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/boreal/infra/modules/edge/main.tf:217:18:\ncalled `Result::unwrap()` on an `Err` value: SendError { .. }\n\nstack backtrace:\n 0: std::panicking::begin_panic_handler\n 1: core::panicking::panic_fmt\n 2: core::result::unwrap_failed\n 3: borealbirchmigratorflow::scheduler::LeaseTask::flush\n at ./projects/boreal/infra/modules/edge/main.tf:217:18\n 4: borealbirchmigratorflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nFind the source of this BorealBirchMigratorFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Test Suite 'BorealSpruceDaemonFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealSpruceDaemonFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/config/staging.toml:144: error: -[BorealSpruceDaemonFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[BorealSpruceDaemonFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nDetermine why BorealSpruceDaemonFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Before touching projects/boreal/engine/render/atlas.cpp, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"# CI job 42147: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Kafka\n\n[setup] restoring cache key deps-a2f91c ... hit\n[setup] starting postgres:17 ... healthy after 4.2s\n[setup] starting redis:8 ... healthy after 0.8s\n[test] shard 3/8 selected 412 tests\n[test] BorealLumenChartFlowIntegration.replays_after_timeout ... ok\n[test] BorealLumenChartFlowIntegration.cancels_orphaned_batch ... FAILED\n\nExpected:\n pending_jobs{queue=\"replay\"} 0\nActual:\n pending_jobs{queue=\"replay\"} 1\n\nCaptured spans:\n batch.receive 2.1ms status=ok\n storage.transaction 44.8ms status=cancelled\n batch.nack <missing>\n\nteardown warning: resource still in use: redis connection pool (1 borrower)\nretry 1/2 with identical seed ... passed\nretry 2/2 with identical seed ... passed\n\nThe failure began after the test suite was sharded, but it sometimes appears on an unsharded nightly run. There are no wall-clock sleeps in this test; it advances the fake scheduler until idle.\n\nWire BorealLumenChartFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Checkout: projects/boreal/src/sync/reconcile.ts now contains BorealKiteSchedulerFlow's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'BorealWrenExportFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealWrenExportFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/ui/settings/PrivacyPane.tsx:144: error: -[BorealWrenExportFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[BorealWrenExportFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nUse the UI evidence to complete BorealWrenExportFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Exporter: # projects/boreal/ui/settings/PrivacyPane.tsx\n[worker.borealprismcacheflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealprismcacheflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealprismcacheflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealPrismCacheFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42137\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/boreal/ui/settings/PrivacyPane.tsx and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Scheduler: // projects/boreal/Sources/CLI/Commands/Doctor.swift\nfinal class BorealAsterWebhookFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit BorealAsterWebhookFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-42112\n\n08:02 deploy BorealIrisBatchFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the BorealIrisBatchFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-42129: retire the legacy replay path for BorealCopperBridgeFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Turn the artifact into a reversible BorealCopperBridgeFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Outline a safer BorealCraneWorkspaceStore cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-42110: finish the compact BorealMosaicGridFlow filter experience\n\nRoute: /catalog/search\nSource: projects/boreal/Sources/CLI/Commands/Doctor.swift\nFramework: Spring Boot\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible BorealMosaicGridFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/boreal/web/components/FilterDrawer.vue b/projects/boreal/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/web/components/FilterDrawer.vue\n+++ b/projects/boreal/web/components/FilterDrawer.vue\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nSplit BorealTideWorkerFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealCinderAuthCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"How should BorealLedgerGateStore be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Em projects/boreal/cmd/exporter/main.py, o BorealNovaPickerStore tem um problema intermitente no fluxo de Spring Boot. Proponha fases, compatibilidade, métricas, rollback e ownership; pare antes de alterar código.\n\nRestrições:\n- continuar com Spring Boot\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao BorealNovaPickerStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"pt"}
{"prompt":"Dashboard: Incident timeline — INC-42146\n\n08:02 deploy BorealCinderAuthFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the material above into a concise BorealCinderAuthFlow release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"A previously stable test around BorealOpalRouterStore now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Worker: The BorealWillowCodecFlow feature flag default should be false in test, exactly like production; correct that config entry and nothing else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"PM is preparing the BorealMosaicGridService rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealMosaicGridService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"BorealMapleQueueStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/boreal/ml/pipeline/features.py and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"BorealAsterWebhookCoordinator needs a paired pass: change BorealAsterWebhookCoordinator's known staging timeout from 15 to 30 seconds, plus give the existing implementation a read-only safety pass. Use projects/boreal/Sources/App/SessionStore.swift as the source of truth, preserve the Spring Boot contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"BorealCopperBridgeService flakes under UTC","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"projects/boreal/services/ledger/replay.go の BorealRavenSessionService で、Kotlin coroutines の flow に断続的な問題が起きています。 responsive layout、empty/retry state、keyboard focus、dark mode、reduced motion を仕上げてください。\n\n制約:\n- Kotlin coroutines を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は BorealRavenSessionService のみ","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"ja"}
{"prompt":"Please resist widening this one: BorealMarbleTokenStore works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealMarbleTokenStore\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Simulator: // projects/boreal/workers/thumbnail/consumer.ex\nfinal class BorealRainfallDBFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nWalk through what the artifact proves about BorealRainfallDBFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"UI ticket DES-42134: finish the compact BorealOpalRouterFlow filter experience\n\nRoute: /catalog/search\nSource: projects/boreal/pkg/cache/lease.rs\nFramework: Cloudflare Workers\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible BorealOpalRouterFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Walk through BorealJuniperCLIService's segment.rs","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealPrismCacheCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealDeltaCanvasCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Summarize the BorealWrenExportService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealMoonlitSDKCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/boreal/packages/api/openapi.yaml b/projects/boreal/packages/api/openapi.yaml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/packages/api/openapi.yaml\n+++ b/projects/boreal/packages/api/openapi.yaml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nSplit BorealDeltaCanvasFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Match BorealPineMetricsService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Incident timeline — INC-42158\n\n08:02 deploy BorealMarbleTokenCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the material above into a concise BorealMarbleTokenCoordinator release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a BorealDriftConsoleFlow changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Why is BorealLedgerGateService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"What sequence would let BorealDeltaCanvasService adopt Cloudflare Workers with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Enforce BorealTideWorkerStore's idempotency key","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Ownership of BorealCoralUploadStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current GraphQL operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Documente o contrato de BorealRainfallDBService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current BorealAmberFilterService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealAmberFilterService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Extract BorealCedarPolicyService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Does BorealPineMetricsStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"projects/boreal/cmd/exporter/main.py has grown through several launches, and BorealBeaconStoreStore now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to BorealBeaconStoreStore and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-42155: retire the legacy replay path for BorealMapleQueueCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nUsing this as the starting evidence, propose a staged BorealMapleQueueCoordinator migration with compatibility seams, owners, canary metrics, rollback gates, and a no-code first milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Runbook: diff --git a/projects/boreal/web/components/FilterDrawer.vue b/projects/boreal/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/web/components/FilterDrawer.vue\n+++ b/projects/boreal/web/components/FilterDrawer.vue\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Restructure BorealAmberFilterFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealSableParserStore's staging timeout is already known to be wrong: change the single projects/boreal/infra/modules/edge/main.tf value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale BorealKiteSchedulerService value; the cause, desired value, and affected assertion are already agreed. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current GraphQL operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Trace: Ticket OPS-42150: retire the legacy replay path for BorealBasilRunnerCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess BorealBasilRunnerCoordinator for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"What does BorealJuniperCLIStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Outline a safer BorealAcornWidgetService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Profiler: Incident timeline — INC-42144\n\n08:02 deploy BorealFlintTimelineFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for BorealFlintTimelineFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Console: # projects/boreal/internal/auth/refresh.go\n[worker.borealacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.borealacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.borealacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.BorealAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-42118\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nMake the one confirmed configuration correction in projects/boreal/internal/auth/refresh.go. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Workspace: projects/boreal/apps/console/routes/usage.svelte の BorealEmberRelayFlow で、GraphQL の flow に断続的な問題が起きています。 consumer 向けに contract、error、retry、コピー可能な例を含む文書を書き、handler は変更しないでください。\n\n制約:\n- GraphQL を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は BorealEmberRelayFlow のみ","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"ja"}
{"prompt":"Fresh release brief for BorealMosaicGridCoordinator:\n- primary outcome: finish BorealMosaicGridCoordinator's responsive empty and retry states\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/boreal/Sources/App/SessionStore.swift\n- platform constraint: Spring Boot\n- known complication: two validators with subtly different error strings\n\nBoth results are required, but they should remain independently reviewable. Leave generated files and vendored code alone; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"PM is preparing the BorealVelaDrawerService rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealVelaDrawerService\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Repository: Release verification found a single stale BorealMosaicGridStore value; the cause, desired value, and affected assertion are already agreed. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Spring Boot operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Read projects/boreal/Sources/App/SessionStore.swift and tell me whether BorealGarnetModalService can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Assess the BorealAcornWidgetStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealLumenChartStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/boreal/ui/settings/PrivacyPane.tsx and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Give BorealEchoRegistryFlow's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Split projects/boreal/app/src/main/SyncWorker.kt by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Ownership of BorealBasilRunnerService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Spring Boot operational envelope\n\nThe relevant code crosses computer vision, React, PostgreSQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"BorealFrostPanelCoordinator: sequence, then restructure","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-42154\n\n08:02 deploy BorealDriftConsoleCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the BorealDriftConsoleCoordinator decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Documente le contrat BorealQuartzPlayerService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"How does BorealEchoRegistryStore propagate cancellation through the Kotlin coroutines boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter BorealAtlasSearchFlow\n RUN v3.2.4 /workspace/apps/console\n × BorealAtlasSearchFlow > restores a suspended upload after reconnect 1543ms\n → expected cursor \"seg-0184\" to equal \"seg-0183\"\n\nAssertionError: expected 'seg-0184' to deeply equal 'seg-0183'\n at packages/sync/test/reconnect.spec.ts:188:31\n at async withFakeClock (packages/testkit/clock.ts:72:9)\n at async Promise.all (index 1)\n\nstdout:\n session=42111 phase=resume storedCursor=seg-0183\n session=42111 phase=fetch requestCursor=seg-0183 pageSize=200\n session=42111 phase=commit receivedCursor=seg-0184 itemCount=0\n session=42111 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the BorealAtlasSearchFlow failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Pipeline: What is the safest way to split projects/boreal/apps/console/routes/usage.svelte into independently owned modules while BorealMoonlitSDKService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"Add a bounded BorealBasilRunnerStore export stream that resumes from checkpoints, respects cancellation, and exposes queue lag plus terminal failure counters.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up BorealIrisBatchCoordinator. First, separate BorealIrisBatchCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/boreal/lib/codec/frame.cc, which follows Kafka conventions and currently suffers from a misleading timeout name used in five packages. Leave generated files and vendored code alone.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"For BorealPineMetricsCoordinator, finish BorealPineMetricsCoordinator's responsive empty and retry states; once that is complete, give the existing implementation a read-only safety pass. Work from projects/boreal/ml/pipeline/features.py, stay with Spring Boot, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"En projects/boreal/apps/console/routes/usage.svelte, BorealAtlasSearchStore tiene un problema intermitente en el flujo de GraphQL. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con GraphQL\n- conservar compatibilidad y cancelación\n- limitar el cambio a BorealAtlasSearchStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con GraphQL alrededor de BorealAtlasSearchStore.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"BorealLumenChartCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Two asks around BorealCopperBridgeCoordinator: (1) ship the idempotent BorealCopperBridgeCoordinator replay endpoint; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Clarify BorealSlateEditorStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-42116: finish the compact BorealCoralUploadFlow filter experience\n\nRoute: /catalog/search\nSource: projects/boreal/db/migrations/20260730_events.sql\nFramework: GraphQL\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible BorealCoralUploadFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"BorealTideWorkerCoordinator needs a paired pass: assess ownership and failure handling in projects/boreal/services/ledger/replay.go, plus capture the contract and rollback note for consumers. Use projects/boreal/services/ledger/replay.go as the source of truth, preserve the Kotlin coroutines contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Clarify BorealCloudReconcilerService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/boreal/apps/console/routes/usage.svelte:217:18:\ncalled `Result::unwrap()` on an `Err` value: SendError { .. }\n\nstack backtrace:\n 0: std::panicking::begin_panic_handler\n 1: core::panicking::panic_fmt\n 2: core::result::unwrap_failed\n 3: borealmoonlitsdkflow::scheduler::LeaseTask::flush\n at ./projects/boreal/apps/console/routes/usage.svelte:217:18\n 4: borealmoonlitsdkflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nReconstruct the BorealMoonlitSDKFlow failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-42159: retire the legacy replay path for BorealSummitProxyCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess BorealSummitProxyCoordinator for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealOpalRouterCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"BorealSpruceDaemonService's metric is misspelled as succesful_total in one declaration. Correct that literal and its exact test expectation, without renaming anything else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for BorealAmberFilterCoordinator:\n- primary outcome: separate BorealAmberFilterCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/boreal/services/ledger/replay.go\n- platform constraint: Kotlin coroutines\n- known complication: stale cursors when a page is resumed\n\nBoth results are required, but they should remain independently reviewable. Leave generated files and vendored code alone; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Compare BorealHarborIndexStore's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The BorealOspreyJobService feature flag default should be false in test, exactly like production; correct that config entry and nothing else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"BorealNovaPickerCoordinator: polish the last piece","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"For BorealCloudReconcilerCoordinator, finish BorealCloudReconcilerCoordinator's responsive empty and retry states; once that is complete, give the existing implementation a read-only safety pass. Work from projects/boreal/apps/console/routes/usage.svelte, stay with GraphQL, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"The first BorealPrismCacheStore request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"BorealWrenExportCoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/boreal/apps/console/routes/usage.svelte b/projects/boreal/apps/console/routes/usage.svelte\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/apps/console/routes/usage.svelte\n+++ b/projects/boreal/apps/console/routes/usage.svelte\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Split BorealSlateEditorFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Gateway: Ticket OPS-42131: retire the legacy replay path for BorealCloudReconcilerFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the material above into a concise BorealCloudReconcilerFlow release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealLedgerGateCoordinator: restructure, then correct","purpose":"refactor","secondary":"backendImpl","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"projects/boreal/ml/pipeline/features.py 里的 BorealNovaPickerService 最近在 Spring Boot 流程中出现间歇性问题。 请写一份面向调用方的说明，包含 contract、错误、retry 和可复制示例，不要改 handler。\n\n约束：\n- 继续使用 Spring Boot\n- 保持兼容性和取消语义\n- 改动只限于 BorealNovaPickerService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"zh"}
{"prompt":"Rename BorealTideWorkerService's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-42145: retire the legacy replay path for BorealMicaProfileFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Map a safe route from the current BorealMicaProfileFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"En projects/boreal/services/ledger/replay.go, BorealEchoRegistryService tiene un problema intermitente en el flujo de Kotlin coroutines. Lee el flujo actual y dime si ownership, cancelación y orden son seguros; solo necesito el análisis.\n\nRestricciones:\n- seguir con Kotlin coroutines\n- conservar compatibilidad y cancelación\n- limitar el cambio a BorealEchoRegistryService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"es"}
{"prompt":"BorealCoralUploadCoordinator: polish, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Persist BorealCoralUploadService's replay cursor","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter BorealCraneWorkspaceFlow\n RUN v3.2.4 /workspace/apps/console\n × BorealCraneWorkspaceFlow > restores a suspended upload after reconnect 1543ms\n → expected cursor \"seg-0184\" to equal \"seg-0183\"\n\nAssertionError: expected 'seg-0184' to deeply equal 'seg-0183'\n at packages/sync/test/reconnect.spec.ts:188:31\n at async withFakeClock (packages/testkit/clock.ts:72:9)\n at async Promise.all (index 1)\n\nstdout:\n session=42132 phase=resume storedCursor=seg-0183\n session=42132 phase=fetch requestCursor=seg-0183 pageSize=200\n session=42132 phase=commit receivedCursor=seg-0184 itemCount=0\n session=42132 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the BorealCraneWorkspaceFlow failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-42138\n\n08:02 deploy BorealSableParserFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for BorealSableParserFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"A copied hex color in BorealMicaProfileService lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: BorealOrbitSyncStore works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside BorealOrbitSyncStore\n- leave generated files and vendored code alone\n\nThis repository spans computer vision, React, PostgreSQL; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealAtlasSearchCoordinator is blocking the next release because memory growth during hour-long imports. I need two concrete outcomes from a single pass: change BorealAtlasSearchCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing GraphQL conventions in projects/boreal/apps/console/routes/usage.svelte; leave generated files and vendored code alone. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Summarize the BorealCloudReconcilerStore changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Does BorealBirchMigratorStore enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"We expect BorealMapleQueueService to outgrow its current Spring Boot arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to BorealMapleQueueService and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_42126'\n AND e.created_at >= now() - interval '24 hours'\nGROUP BY e.tenant_id, e.stream_id;\n\nHashAggregate (cost=184922.10..185011.81 rows=8971 width=40) (actual time=8421.294..8422.551 rows=123 loops=1)\n Group Key: e.tenant_id, e.stream_id\n Batches: 1 Memory Usage: 945kB\n -> Hash Join (cost=2118.42..181004.17 rows=522391 width=32) (actual time=42.118..8279.405 rows=918412 loops=1)\n Hash Cond: ((e.tenant_id = s.tenant_id) AND (e.stream_id = s.id))\n -> Bitmap Heap Scan on event_log e (actual time=18.602..7922.884 rows=1261044 loops=1)\n Recheck Cond: (tenant_id = 't_42126'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nWire BorealCedarPolicyFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"BorealFernSnapshotCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/boreal/engine/render/atlas.cpp b/projects/boreal/engine/render/atlas.cpp\nindex 62d71aa..90f3c1e 100644\n--- a/projects/boreal/engine/render/atlas.cpp\n+++ b/projects/boreal/engine/render/atlas.cpp\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is BorealWillowCodecCoordinator's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"A copied hex color in BorealMapleQueueFlow lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Where did BorealCedarPolicyStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"Is there a cleaner way to separate BorealVelaDrawerFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Dedupe BorealAsterWebhookService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"We expect BorealSummitProxyStore to outgrow its current Cloudflare Workers arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to BorealSummitProxyStore and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Is BorealCopperBridgeStore safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: BorealWillowCodecService has one known configuration mistake in projects/boreal/lib/codec/frame.cc, not an open-ended failure investigation. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to BorealWillowCodecService and its direct tests\n\nSeveral teams work in this computer vision, React, PostgreSQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"BorealRavenSessionCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'BorealLedgerGateFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[BorealLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/boreal/services/ledger/replay.go:144: error: -[BorealLedgerGateFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[BorealLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nUse the UI evidence to complete BorealLedgerGateFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
data/round2-03.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "a contractor is about to touch our authentication middleware and i'd like a second read on it first: how the tenant is resolved, what happens when the header is present but the token is for another tenant, and whether the viewer role can reach any write path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "our error responses are a mix of plain strings, a `{error}` object and RFC 7807 problem details depending on the endpoint's age — pick the newest shape and apply it everywhere without changing status codes", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "the conflict drawer in the desktop app needs to actually show what changed, field by field, with a choice per conflict", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "training run died overnight at epoch 31 of 60 and i lost the checkpoint:\n\nTraceback (most recent call last):\n File \"train.py\", line 212, in <module>\n main(cfg)\n File \"train.py\", line 168, in main\n loss.backward()\n File \"/opt/conda/lib/python3.11/site-packages/torch/_tensor.py\", line 581, in backward\n torch.autograd.backward(self, gradient, retain_graph, create_graph, inputs=inputs)\n File \"/opt/conda/lib/python3.11/site-packages/torch/autograd/__init__.py\", line 347, in backward\n _engine_run_backward(\ntorch.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.44 GiB. GPU 0 has a total capacity of 79.15 GiB of which 1.88 GiB is free. Process 41221 has 77.2 GiB memory in use. Of the allocated memory 71.44 GiB is allocated by PyTorch, and 4.91 GiB is reserved by PyTorch but unallocated.\n\nbatch size hasn't changed, and epochs 1 through 30 were fine on the same node", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "a walkthrough of how a route goes from saved to solved to dispatched, naming the services and queues involved, would save me a week", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "our error codes appear in three places and are documented in none; produce the reference table from `errors.rs` with a sentence per code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "the whole reassignment flow, honestly", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "stop popover cuts off at the right edge", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "desktop app freezes after sleep", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "training script has config handling scattered through it and i keep breaking runs by changing a default. same behaviour, one place:\n\nparser.add_argument(\"--lr\", type=float, default=3e-4)\nparser.add_argument(\"--batch-size\", type=int, default=64)\n...\ncfg = yaml.safe_load(open(args.config))\nlr = args.lr or cfg.get(\"lr\", 3e-4)\nbs = int(os.environ.get(\"BATCH_SIZE\", args.batch_size))\nif cfg.get(\"scheduler\") == \"cosine\":\n warmup = cfg.get(\"warmup\", 500)\nelse:\n warmup = int(os.environ.get(\"WARMUP\", 0))\nseed = cfg.get(\"seed\") if \"seed\" in cfg else args.seed if args.seed else 42\ngrad_accum = cfg.get(\"grad_accum\", 1) * (2 if os.environ.get(\"BIG_NODE\") else 1)", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "an intermittent one, maybe once a day, from the desktop app's crash reporter:\n\nProcess: FleetDesk [4471]\nPath: /Applications/FleetDesk.app/Contents/MacOS/FleetDesk\nIdentifier: io.fleetdesk.app\nVersion: 2.8.1 (2810)\nCode Type: ARM-64\nCrashed Thread: 0 Dispatch queue: com.apple.main-thread\n\nException Type: EXC_BAD_ACCESS (SIGSEGV)\nException Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010\n\nThread 0 Crashed:\n0 FleetDesk 0x104a2c118 node::Buffer::Data(v8::Local<v8::Value>) + 24\n1 FleetDesk 0x104b19a44 better_sqlite3::Statement::Run(...) + 388\n2 FleetDesk 0x1051220c8 v8::internal::Builtin_HandleApiCall + 296\n\nalways within a minute of the app coming back from sleep", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "before i approve this, is the locking sound? two dispatchers can assign the same driver today:\n\n@Transactional\npublic Assignment assign(UUID routeId, UUID driverId) {\n Route route = routeRepo.findById(routeId).orElseThrow();\n Driver driver = driverRepo.findById(driverId).orElseThrow();\n if (assignmentRepo.existsByDriverIdAndDayAndStatus(driverId, route.getDay(), ACTIVE)) {\n throw new DriverAlreadyAssigned(driverId);\n }\n Assignment a = new Assignment(route, driver, ACTIVE, Instant.now());\n assignmentRepo.save(a);\n eventPublisher.publish(new AssignmentCreated(a.getId()));\n notificationClient.notifyDriver(driverId, a.getId());\n return a;\n}\n\npostgres, read committed, two app instances behind a load balancer", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "design doc paragraph that keeps getting quoted at me. is it still accurate given what we built?\n\n\"Route optimisation runs asynchronously. When a planner saves a route, we enqueue a solve job and return immediately with the previous solution. The client polls /v1/routes/{id} until `solution_version` increases. Solves are idempotent per (route_id, input_hash), so re-enqueueing the same inputs is free. A solve never blocks the planner's UI, and a failed solve leaves the last good solution in place.\"\n\nas far as i can tell the desktop app blocks on save, and we removed input_hash in march", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "same guard clause copy-pasted into nine handlers, and two of them have it subtly wrong:\n\n// handlers/assignments.rs\nif !ctx.tenant_id.is_some() { return Err(Error::Unauthorized) }\nif ctx.role != Role::Dispatcher && ctx.role != Role::Admin { return Err(Error::Forbidden) }\n\n// handlers/routes.rs\nif ctx.tenant_id.is_none() { return Err(Error::Unauthorized) }\nif !matches!(ctx.role, Role::Dispatcher | Role::Admin | Role::Planner) { return Err(Error::Forbidden) }\n\n// handlers/drivers.rs\nif ctx.tenant_id.is_none() { return Err(Error::Unauthorized) }\nif ctx.role == Role::Viewer { return Err(Error::Forbidden) }\n\nthe intent everywhere is the same: authenticated, and not a viewer", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "solver time limit to 12s in prod", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "planner screen, obviously", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "`stop_seq` naming, pick one spelling", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "desktop release cadence is monthly and every release has a scramble at the end for notarization, changelog and the update feed. i'd like the whole release process designed properly — what's automated, what's a human gate, how we do staged rollout for an electron app, and how we roll back a bad update that's already downloaded", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "ipc surface has grown one handler per screen and they all do the same three steps. same behaviour, one registration point:\n\nipcMain.handle('routes:list', async (_e, filter) => {\n const t0 = Date.now()\n try { return { ok: true, data: await routes.list(filter) } }\n catch (e) { log.error('routes:list', e); return { ok: false, error: String(e) } }\n finally { metrics.timing('ipc.routes.list', Date.now() - t0) }\n})\n\nipcMain.handle('drivers:list', async (_e, filter) => {\n const t0 = Date.now()\n try { return { ok: true, data: await drivers.list(filter) } }\n catch (e) { log.error('drivers:list', e); return { ok: false, error: String(e) } }\n finally { metrics.timing('ipc.drivers.list', Date.now() - t0) }\n})\n\n// ...eleven more of these", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "vehicle bands need alternating backgrounds", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "map legend overlaps the zoom control", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "driver list scrolls behind the header", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "one latlng converter across the packages", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "what does `--relax-windows` actually do?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "is our idempotency key tenant-scoped?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "we owe our biggest customer a written explanation of last week's four-hour degradation, and they will read it carefully because their SLA credits depend on it. the facts are in the incident channel and the timeline is in grafana. write the customer-facing version — honest, specific about impact, clear about what changes, no engineering jargon", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "assignment, route and trip mean three different things in the java service depending on which file you're in, and two of them are swapped relative to the public API. rename everything internal to match what the API calls things, leave the json field names untouched, and do it in a way that's reviewable rather than one 4000-line commit", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "feature building happens in the training script, the evaluation script and the inference service, and the three have quietly diverged. bring them onto one implementation, and once they agree, document which features exist and where each comes from", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "public API changelog needs an entry for the new `sequence` field on the ETA payload, and partners need to know it's monotonic per route", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "how should we version the partner-facing API once the ETA push exists — header, path, or something else? i want a recommendation with reasoning", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "stop-level ETAs should be persisted rather than recomputed on every read, and the reporting team wants the history", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "design spec for the route timeline in the desktop app, build it with our vue components:\n\nRoute timeline (desktop, 1440px+)\n- Horizontal band per vehicle, 44px tall, stacked with 8px gaps, virtualised past 40 vehicles.\n- Time axis pinned at the top, hour ticks, current time as a 2px accent line with a small label.\n- Stops render as blocks proportional to service time, minimum 12px wide, 2px radius; late stops get a hatched fill.\n- Hovering a stop shows a popover with address, window, ETA and delay; keyboard focus does the same.\n- Dragging a stop between bands reassigns it, with a drop shadow and a live delta badge showing the ETA change.\n- Selection: click selects, shift-click range selects within a band, escape clears.\n- Zoom control at 4 steps (whole day / 6h / 2h / 30m), keeps the pointer position anchored.\n- Empty band shows \"No stops assigned\" and stays droppable.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "solver returns empty on 900-stop routes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "same as the last one but bigger", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "an intermittent report from two fleets that a stop occasionally shows on the wrong vehicle for a few seconds after a reassignment, then corrects itself. that smells like an optimistic update racing the pull, but i can't reproduce it and neither can support", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "planner grid is unusable with a screen reader according to a customer, and it's our own component rather than a library. make it keyboard navigable with a proper grid role, add a keyboard alternative to drag and drop, and stop using colour alone for the delay column", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "before we build the ETA push i want the design written — transport, sequencing, backpressure, what we do when a partner's endpoint is down — and then the outbound sender itself, against whatever we land on", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "routing service panicked in prod, first time in eight months:\n\nthread 'route-worker-3' panicked at src/solver/insertion.rs:212:34:\nindex out of bounds: the len is 0 but the index is 0\nstack backtrace:\n 0: rust_begin_unwind\n 1: core::panicking::panic_fmt\n 2: core::panicking::panic_bounds_check\n 3: fleetd::solver::insertion::best_insertion\n at ./src/solver/insertion.rs:212:34\n 4: fleetd::solver::Solver::improve\n at ./src/solver/mod.rs:88:21\n 5: fleetd::worker::handle_job\n at ./src/worker.rs:141:9\n 6: tokio::runtime::task::harness::Harness<T,S>::poll\nnote: Some details are omitted, run with `RUST_BACKTRACE=full`\n\njob 88421, 0 stops, 4 vehicles — a depot with no deliveries scheduled, which shouldn't be a job at all", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "electron main process log from a customer whose app hangs on launch, macOS 15:\n\n[main] app ready in 412ms\n[main] creating BrowserWindow 1200x800\n[updater] checking https://releases.fleetdesk.io/latest-mac.yml\n[db] opening sqlite at /Users/x/Library/Application Support/FleetDesk/local.db\n[db] running migration 0041_add_route_cache\n[db] migration 0041 took 18441ms\n[main] window did-finish-load\n[renderer] hydrating 41 cached routes\n[renderer] Uncaught (in promise) Error: IPC channel closed\n at EventEmitter.<anonymous> (renderer.js:1:88112)\n[main] window unresponsive\n[main] window responsive\n[main] window unresponsive\n\nthey have about 90k rows in route_cache, most users have a few hundred", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "java service throwing these under load, about 40 a minute since the last deploy:\n\njava.util.concurrent.TimeoutException: Did not observe any item or terminal signal within 30000ms in 'flatMap' (and no fallback has been configured)\n\tat reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.handleTimeout(FluxTimeout.java:295)\n\tat io.fleet.dispatch.AssignmentService.assign(AssignmentService.java:141)\n\tat io.fleet.dispatch.DispatchController.postAssignment(DispatchController.java:66)\n\tSuppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:\nError has been observed at the following site(s):\n\t*__checkpoint ⇢ Request to POST /v1/assignments [DispatchHandler]\nOriginal Stack Trace:\n\t\tat io.fleet.dispatch.AssignmentService.lambda$assign$4(AssignmentService.java:139)\n\nthe downstream geocoder it calls reports p99 of 80ms and no errors", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "mqtt broker log from the depot gateway, devices drop off in batches:\n\n1753843201: New client connected from 10.2.4.71 as gw-depot-04 (p2, c0, k60, u'depot')\n1753843261: Client gw-depot-04 has exceeded timeout, disconnecting.\n1753843262: New client connected from 10.2.4.71 as gw-depot-04 (p2, c0, k60, u'depot')\n1753843263: Client gw-depot-04 already connected, closing old connection.\n1753843323: Client gw-depot-04 has exceeded timeout, disconnecting.\n1753843324: New connection from 10.2.4.71 on port 8883.\n1753843324: Client gw-depot-04 disconnected due to protocol error.\n1753843384: Socket error on client gw-depot-11, disconnecting.\n1753843385: Client gw-depot-11 disconnected: Out of memory.\n\nbroker memory sits at 60% and the network graph is flat", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "git bisect finished and i don't believe the result:\n\n41c9e0b8f2a1d3e4c5a6b7c8d9e0f1a2b3c4d5e6 is the first bad commit\ncommit 41c9e0b8f2a1d3e4c5a6b7c8d9e0f1a2b3c4d5e6\nAuthor: dana <[email protected]>\nDate: Tue Jul 14 09:12:44 2026 +0200\n\n chore: enable strict null checks in the shared package\n\n tsconfig.base.json | 3 ++-\n packages/shared/src/geo.ts | 12 +++++------\n 2 files changed, 8 insertions(+), 7 deletions(-)\n\nbisect run success\n\nthe symptom is that route ETAs are 3-4 minutes off in the desktop app but correct in the web app, and this commit doesn't touch either of them directly", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "kubectl describe on the training job pod, it never gets scheduled:\n\nEvents:\n Type Reason Age From Message\n ---- ------ ---- ---- -------\n Warning FailedScheduling 4m12s default-scheduler 0/14 nodes are available: 6 Insufficient nvidia.com/gpu, 8 node(s) had untolerated taint {workload: training}\n Normal NotTriggerScaleUp 3m50s cluster-autoscaler pod didn't trigger scale-up: 2 max node group size reached, 1 node(s) had volume node affinity conflict\n Warning FailedScheduling 2m01s default-scheduler 0/14 nodes are available: 6 Insufficient nvidia.com/gpu, 8 node(s) had untolerated taint {workload: training}\n\nrequests: nvidia.com/gpu: 4, memory: 200Gi\ntolerations: [{key: workload, operator: Equal, value: inference}]\n\nthe same manifest worked last week", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "des tests flaky depuis lundi, toujours les mêmes trois, jamais en local :\n\nFAILED tests/test_routing.py::test_two_vehicles_share_a_depot - AssertionError: assert 41.2 == approx(41.19999999 ± 1.0e-06)\nFAILED tests/test_routing.py::test_time_windows_respected - IndexError: list index out of range\nFAILED tests/test_eta.py::test_eta_matches_matrix - assert datetime(2026, 7, 27, 14, 3) == datetime(2026, 7, 27, 14, 2)\n\n=========================== short test summary info ============================\n3 failed, 1841 passed, 12 skipped in 214.88s\n\nrandom seed: 8412 (pytest-randomly)\nworkers: 8 (pytest-xdist)\n\nsur ma machine avec -p no:randomly tout passe", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "fr"}
{"prompt": "valgrind on the gateway firmware simulator, it leaks a few KB an hour in the field:\n\n==41221== HEAP SUMMARY:\n==41221== in use at exit: 84,112 bytes in 1,204 blocks\n==41221== total heap usage: 88,441 allocs, 87,237 frees, 12,884,112 bytes allocated\n==41221==\n==41221== 68,224 bytes in 1,066 blocks are definitely lost in loss record 41 of 44\n==41221== at 0x4C2FB0F: malloc (vg_replace_malloc.c:299)\n==41221== by 0x40A112: telemetry_frame_new (telemetry.c:88)\n==41221== by 0x40B4C0: on_publish_ack (mqtt_handlers.c:141)\n==41221== by 0x40C219: mqtt_loop (mqtt_client.c:412)\n==41221== by 0x401E77: main (main.c:66)\n==41221==\n==41221== LEAK SUMMARY:\n==41221== definitely lost: 68,224 bytes in 1,066 blocks\n==41221== indirectly lost: 15,888 bytes in 138 blocks", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "data loader someone added last sprint. does this actually shuffle the way we think it does?\n\nclass RouteDataset(IterableDataset):\n def __init__(self, shards, batch_size=64, shuffle_buffer=10_000):\n self.shards = shards\n self.batch_size = batch_size\n self.shuffle_buffer = shuffle_buffer\n\n def __iter__(self):\n info = get_worker_info()\n shards = self.shards if info is None else self.shards[info.id::info.num_workers]\n buf = []\n for shard in shards:\n for row in read_parquet_rows(shard):\n buf.append(row)\n if len(buf) >= self.shuffle_buffer:\n random.shuffle(buf)\n yield from batched(buf, self.batch_size)\n buf = []\n if buf:\n yield from batched(buf, self.batch_size)\n\nfour workers, 200 shards, and validation loss is suspiciously smooth", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "openapi we publish for partners, section for the assignment endpoint. does this match what a sane client would expect?\n\n /v1/assignments:\n post:\n operationId: createAssignment\n requestBody:\n required: true\n content:\n application/json:\n schema:\n type: object\n required: [route_id]\n properties:\n route_id: { type: string, format: uuid }\n driver_id: { type: string, format: uuid, nullable: true }\n force: { type: boolean, default: false }\n responses:\n '200': { description: created }\n '409': { description: conflict }\n '422': { description: unprocessable }\n default: { description: error }\n\nno schemas on any response, and `force` isn't described anywhere else either", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "benchmark numbers from the solver rewrite. is this a real win or did we just move the cost around?\n\n old new delta\nsolve_small (20 stops) 4.2ms 1.1ms -74%\nsolve_med (120 stops) 88ms 31ms -65%\nsolve_large (900 stops) 6.1s 7.8s +28%\nmemory_large 210MB 1.4GB +566%\nfirst_feasible_large 0.9s 4.4s +388%\nalloc_count_large 88k 2.1M +2286%\n\ncriterion, 100 samples, same machine, both release builds with lto=thin\n\nmost of our customers are in the 50-300 stop range but our three biggest accounts are all above 800", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "这是我们同事写的 IPC 层，我看着有点不安全，帮我判断一下：\n\nipcMain.handle('db:query', async (event, sql, params) => {\n const db = getDb()\n return db.prepare(sql).all(...(params ?? []))\n})\n\nipcMain.handle('fs:read', async (event, path) => {\n return fs.promises.readFile(path, 'utf8')\n})\n\nipcMain.on('window:setTitle', (event, title) => {\n BrowserWindow.fromWebContents(event.sender)?.setTitle(title)\n})\n\n// preload.js\ncontextBridge.exposeInMainWorld('api', {\n query: (sql, params) => ipcRenderer.invoke('db:query', sql, params),\n readFile: (p) => ipcRenderer.invoke('fs:read', p),\n})\n\n渲染进程会加载第三方的地图 SDK", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "zh"}
{"prompt": "github actions workflow for the model training image. anything here that explains why builds take 40 minutes?\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: docker/setup-buildx-action@v3\n - run: pip install -r requirements-dev.txt\n - run: pytest -q\n - uses: docker/build-push-action@v6\n with:\n context: .\n push: true\n tags: ghcr.io/fleet/trainer:${{ github.sha }}\n - run: python tools/export_onnx.py --checkpoint artifacts/last.ckpt\n - uses: actions/upload-artifact@v4\n with:\n name: onnx\n path: artifacts/*.onnx\n\nno cache configuration anywhere, and requirements-dev.txt pins torch", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "a short internal note explaining why we're moving inference off the solver box, for the platform team's decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "our health endpoint returns 200 while the solver queue is completely stalled, it should at least check the worker heartbeat", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "the sync indicator in the desktop titlebar has five states in the design and two in the code, so users see a spinner for offline, errors and conflicts alike. implement the full set — idle, syncing after a delay, offline with a pending count, conflict with an amber dot, and a failure state with a retry link — and make sure none of them rely on colour alone", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "training config is read from argparse, a yaml file and environment variables, with precedence that differs per field and one place where they're multiplied together. unify it into a single resolved config object, keep every current default exactly as it is, and make the precedence explicit and testable", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "a nightly export of closed routes to the customer's SFTP, csv, one file per depot, with a manifest and a checksum", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "our on-call rotation covers three services with wildly different failure modes, and the alerting was set up per-service by different people. what should a coherent alerting story look like?", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "the queue implementation has a claim TTL, a heartbeat, a dead-letter threshold and a release command, and every person on the team describes their interaction differently. read it and give me the actual semantics: when a claim expires, what happens to a job whose worker died mid-solve, whether a job can run twice, and what the dead-letter table really means", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "stop detail popover currently opens on hover, closes when the pointer leaves, and traps nothing, which means keyboard users never see it and touch users on the surface tablets get it stuck open. rework it as a proper popover with focus management, an escape key, a small delay before opening, and behaviour that makes sense when the underlying row moves because a sync landed", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "desktop app's local database has grown to a gigabyte for our biggest customers and i don't know whether that's the route cache, the telemetry buffer or something we forgot to prune. work out what's actually in there and which of it is load-bearing", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "training loss goes to NaN somewhere between step 4000 and 6000, but only when we enable the traffic features, and only on the multi-GPU runs. single GPU with the same config and seed is fine for a full epoch", "purpose": "debugging", "secondary": "planning", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "coverage report after the sprint, and management wants a number. what does this actually tell us?\n\nName Stmts Miss Cover Missing\n---------------------------------------------------------------\nfleet/solver/insertion.py 412 18 96% 88-91, 212-218\nfleet/solver/local_search.py 388 141 64% 102-188, 240-291\nfleet/eta/matrix.py 190 4 98% 77-80\nfleet/eta/traffic.py 144 144 0% 1-144\nfleet/api/routes.py 266 31 88% 41-52, 188-201\nfleet/api/assignments.py 180 12 93% 66-77\nfleet/jobs/nightly.py 121 121 0% 1-121\n---------------------------------------------------------------\nTOTAL 1701 471 72%\n\ntraffic.py and nightly.py are the two things that page us most often", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "endpoint below is what partners integrate against, and the only documentation is this handler. write the reference page:\n\n@PostMapping(\"/v1/assignments\")\npublic ResponseEntity<AssignmentDto> post(@RequestBody @Valid AssignmentRequest req,\n @RequestHeader(\"Idempotency-Key\") String key) {\n if (req.driverId() == null && !req.force()) {\n throw new BadRequest(\"driver_id required unless force=true\");\n }\n var existing = idempotency.find(key);\n if (existing != null) return ResponseEntity.ok(existing);\n var a = service.assign(req.routeId(), req.driverId(), req.force());\n idempotency.put(key, a, Duration.ofHours(24));\n return ResponseEntity.status(201).body(AssignmentDto.from(a));\n}\n\nmention that force=true auto-selects the nearest available driver, that 200 means replayed and 201 means created, and that the key is scoped per tenant", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "protobuf schema for the telemetry stream, and partners keep asking what the fields mean. document it properly:\n\nmessage Telemetry {\n string device_id = 1;\n int64 captured_at_ms = 2;\n Position position = 3;\n optional float speed_kph = 4;\n optional float heading_deg = 5;\n optional int32 battery_pct = 6;\n repeated Event events = 7;\n reserved 8 to 11;\n string firmware = 12;\n}\n\nmessage Event {\n enum Kind { UNKNOWN = 0; HARSH_BRAKE = 1; IDLE_START = 2; IDLE_END = 3; DOOR_OPEN = 4; }\n Kind kind = 1;\n int64 at_ms = 2;\n map<string, string> attrs = 3;\n}\n\nthings only we know: captured_at_ms is device clock and can be wrong by minutes; heading is absent when stationary; attrs keys are not stable across firmware versions", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "notas de la reunión con operaciones, hay que convertirlas en el documento de requisitos:\n\n- los conductores fichan desde el móvil pero el sistema no sabe si están en el depósito o en ruta\n- las rutas se cierran a las 22:00 aunque el conductor siga entregando, y luego hay que reabrirlas a mano\n- los cambios de última hora llegan por whatsapp al jefe de tráfico, nunca al sistema\n- quieren ver el retraso acumulado por ruta en tiempo real, hoy lo calculan en una hoja de cálculo\n- dos depósitos comparten flota los viernes y eso no se puede modelar\n- si un camión se avería, reasignar sus paradas lleva veinte minutos de trabajo manual", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "es"}
{"prompt": "model card is empty and legal wants one before this ships to customers. what we know:\n\n- gradient boosted model predicting stop service time from historical telemetry\n- trained on 14 months of data from 61 fleets, 8.2M stops, EU only\n- features: stop type, time of day, weekday, vehicle class, historical median for the location, weather bucket\n- excluded deliberately: driver identity, anything that could act as a proxy for it\n- MAE 2.1 minutes overall, 4.8 minutes for stops with fewer than 5 historical observations\n- known weakness: dense urban centres in cities not in the training set\n- retrained quarterly, no online learning, rollback is a config flag\n\nwrite the model card, audience is a customer's procurement team", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "support escalation thread, needs to become a known-issues entry:\n\n[09:12] tomas: three customers on 2.8.1 say the app freezes for 20-30s after waking the laptop\n[09:14] pri: reproduced on my mac, only when there are unsynced routes\n[09:20] tomas: the sqlite handle goes stale over sleep i think, we reopen it lazily\n[09:31] pri: confirmed, first query after wake blocks and the UI thread is doing it\n[09:44] tomas: workaround for support: quit and reopen the app, nothing is lost\n[10:02] pri: proper fix is reopening on wake and moving queries off the main thread, that's not this week\n[10:15] tomas: 2.8.2 will have the workaround banner at least\n\nwrite the entry the way our other known-issues entries read: symptom, affected versions, workaround, status", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "cli help output, and the manual page we ship is from two versions ago:\n\nfleetctl solve [OPTIONS] <ROUTE_FILE>\n\nArguments:\n <ROUTE_FILE> Route definition in JSON or CSV\n\nOptions:\n -t, --time-limit <SECONDS> Stop after this long [default: 30]\n -s, --seed <SEED> Deterministic seed for the metaheuristic\n --strategy <STRATEGY> [default: guided] [possible values: greedy, guided, exhaustive]\n --vehicles <N> Override the vehicle count in the file\n --relax-windows Allow time window violations, penalised\n --emit-intermediate Print every improvement to stderr as it is found\n --matrix <PATH> Precomputed distance matrix\n -o, --output <PATH> Write the solution here [default: stdout]\n -v, --verbose... Increase logging\n\nrewrite the man page, and note that --exhaustive on more than 200 stops is not practical", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "draft the customer email about the maintenance window from these notes, it goes to 400 fleet managers:\n\n- saturday 09 aug, 01:00 to 05:00 UTC\n- the planning app will be read-only for the whole window, mobile driver app unaffected\n- routes already dispatched keep working, new routes cannot be created\n- reason: moving the route database to a new cluster, needed for the bigger fleets\n- if it overruns we'll extend to 07:00 and post on status.fleetdesk.io\n- no action needed from them, but they should avoid scheduling monday routes on saturday morning\n- support will be staffed throughout", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "o README do repositório do modelo está desatualizado. o que existe hoje:\n\n- treino com `python train.py --config configs/base.yaml`, requer GPU com 40GB+\n- os dados vêm do bucket `fleet-ml-eu`, sincronizados com `make data` (precisa de credenciais AWS)\n- avaliação: `python eval.py --checkpoint <path> --split test`, gera um relatório em `reports/`\n- exportação para ONNX é um passo separado e só funciona com opset 17\n- o serviço de inferência está noutro repositório e espera o modelo em `s3://fleet-models/service-time/vN/`\n- os notebooks em `notebooks/` estão obsoletos, ninguém os usa há um ano\n\nescreve o README para quem chega amanhã", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "pt"}
{"prompt": "cargo audit on the routing service, tell me which of these to bump now and which can wait:\n\nCrate: openssl\nVersion: 0.10.64\nTitle: Use-after-free in SSL session handling\nDate: 2026-06-11\nID: RUSTSEC-2026-0041\nSolution: Upgrade to >=0.10.68\n\nCrate: rustls\nVersion: 0.23.10\nTitle: Panic on malformed certificate chain\nDate: 2026-05-02\nID: RUSTSEC-2026-0033\nSolution: Upgrade to >=0.23.14\n\nCrate: time\nVersion: 0.3.34\nWarning: unmaintained branch\n\nerror: 2 vulnerabilities found, 1 warning", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "typecheck is failing on the desktop app after the shared package change:\n\npackages/desktop/src/routes/RouteTable.tsx:88:24 - error TS2532: Object is possibly 'undefined'.\n88 const eta = route.stops[0].eta.toISOString()\n ~~~~~~~~~~~~~~~\npackages/desktop/src/routes/RouteTable.tsx:141:9 - error TS18048: 'driver' is possibly 'undefined'.\npackages/desktop/src/sync/pull.ts:41:15 - error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.\npackages/desktop/src/sync/pull.ts:66:7 - error TS18047: 'lastSync' is possibly 'null'.\n\nFound 4 errors in 2 files.\n\nstrict null checks got turned on in tsconfig.base.json last week", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "prod config and staging config for the solver, one of these numbers is why staging never reproduces prod timeouts:\n\n# staging/solver.yaml\nsolver:\n time_limit_seconds: 30\n workers: 4\n max_stops_per_job: 2000\n matrix_cache_ttl_minutes: 60\n queue_claim_ttl_seconds: 900\n dead_letter_after: 3\n strategy: guided\n emit_intermediate: true\n heartbeat_seconds: 30\n\n# prod/solver.yaml\nsolver:\n time_limit_seconds: 8\n workers: 24\n max_stops_per_job: 2000\n matrix_cache_ttl_minutes: 5\n queue_claim_ttl_seconds: 900\n dead_letter_after: 3\n strategy: guided\n emit_intermediate: false\n heartbeat_seconds: 30\n\n# what the alert looks like in prod, never in staging\nsolver_job_timeout_total{env=\"prod\"} 41 in the last hour\nsolver_job_timeout_total{env=\"staging\"} 0 in the last 30 days", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "electron-builder config, notarization started failing after the mac runner upgrade:\n\n\"mac\": {\n \"category\": \"public.app-category.business\",\n \"hardenedRuntime\": true,\n \"gatekeeperAssess\": false,\n \"entitlements\": \"build/entitlements.mac.plist\",\n \"entitlementsInherit\": \"build/entitlements.mac.plist\",\n \"notarize\": { \"teamId\": \"8K4L2M9N\" },\n \"target\": [{ \"target\": \"dmg\", \"arch\": [\"arm64\", \"x64\"] }]\n},\n\nerror log:\n • signing file=dist/mac-arm64/FleetDesk.app\n ⨯ notarization failed reason=Team ID is required when using notarytool with an App Store Connect API key\n ⨯ /usr/bin/xcrun exited with code 1", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "eslint on the vue frontend, mostly one rule repeated:\n\n/app/src/components/RouteMap.vue\n 41:3 error Component name \"map\" should always be multi-word vue/multi-word-component-names\n 88:11 error 'watchEffect' is defined but never used @typescript-eslint/no-unused-vars\n 112:7 warning Unexpected mutation of \"stops\" prop vue/no-mutating-props\n\n/app/src/components/StopList.vue\n 22:5 warning Unexpected mutation of \"stops\" prop vue/no-mutating-props\n 67:9 error v-for should have explicit key vue/require-v-for-key\n\n/app/src/views/PlannerView.vue\n 141:1 error Expected indentation of 2 spaces but found 4 vue/html-indent\n\n✖ 6 problems (4 errors, 2 warnings)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "pasted-context", "lang": "en"}
{"prompt": "terraform plan output, i only wanted to change the instance type:\n\nTerraform will perform the following actions:\n\n # aws_instance.solver[0] must be replaced\n -/+ resource \"aws_instance\" \"solver\" {\n ~ instance_type = \"c6i.4xlarge\" -> \"c7i.4xlarge\" # forces replacement\n ~ private_ip = \"10.2.4.71\" -> (known after apply)\n ~ id = \"i-0a11c3f2\" -> (known after apply)\n }\n\n # aws_lb_target_group_attachment.solver[0] must be replaced\n -/+ resource \"aws_lb_target_group_attachment\" \"solver\" {\n ~ target_id = \"i-0a11c3f2\" -> (known after apply) # forces replacement\n }\n\n # aws_ebs_volume.solver_cache[0] will be destroyed\n - resource \"aws_ebs_volume\" \"solver_cache\" {\n - size = 500 -> null\n }\n\nPlan: 2 to add, 0 to change, 3 to destroy.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "dockerfile for the trainer image, it's 14GB and takes forever to push:\n\nFROM nvidia/cuda:12.4.1-devel-ubuntu22.04\nRUN apt-get update && apt-get install -y python3.11 python3-pip git curl build-essential\nCOPY . /workspace\nWORKDIR /workspace\nRUN pip install -r requirements-dev.txt\nRUN pip install -r requirements.txt\nRUN python -c \"import torch; print(torch.__version__)\"\nRUN make data\nENV PYTHONPATH=/workspace\nCMD [\"python\", \"train.py\", \"--config\", \"configs/base.yaml\"]\n\nrequirements-dev.txt includes pytest, ruff, notebook and jupyterlab", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "three functions that convert between our coordinate types, in three files, all slightly different. one of them, please:\n\n// packages/shared/src/geo.ts\nexport const toLatLng = (p: Point): LatLng => ({ lat: p.y, lng: p.x })\n\n// packages/desktop/src/map/convert.ts\nexport function pointToLatLng(p: { x: number; y: number }) {\n return { lat: Number(p.y.toFixed(6)), lng: Number(p.x.toFixed(6)) }\n}\n\n// packages/web/src/lib/coords.ts\nexport const asLatLng = (p: Point | LatLng): LatLng =>\n 'lat' in p ? p : { lat: p.y, lng: p.x }\n\nthe rounding in the desktop one is deliberate — the map SDK chokes on more precision", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "this module has one function doing five things and i want the same output with seams i can test:\n\ndef build_features(stops, telemetry, weather, cfg):\n df = pd.DataFrame([s.__dict__ for s in stops])\n df[\"hour\"] = pd.to_datetime(df[\"arrived_at\"]).dt.hour\n df[\"weekday\"] = pd.to_datetime(df[\"arrived_at\"]).dt.weekday\n tel = pd.DataFrame(telemetry)\n tel = tel[tel[\"speed_kph\"] < 200]\n df = df.merge(tel.groupby(\"stop_id\").agg({\"idle_s\": \"sum\"}), on=\"stop_id\", how=\"left\")\n wx = pd.DataFrame(weather).rename(columns={\"t\": \"temp\"})\n df = df.merge(wx, on=[\"lat_bucket\", \"lon_bucket\", \"hour\"], how=\"left\")\n df[\"temp\"] = df[\"temp\"].fillna(df[\"temp\"].median())\n df[\"hist_median\"] = df.groupby(\"location_id\")[\"service_s\"].transform(\"median\")\n if cfg.drop_sparse:\n df = df[df.groupby(\"location_id\")[\"service_s\"].transform(\"count\") >= 5]\n return df.drop(columns=[\"arrived_at\", \"raw\"]), df[\"service_s\"]", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "legacy naming that predates the fleet/route split, i want it consistent across the java service:\n\nclass TripPlanner { ... } // actually plans routes\nclass RouteService { ... } // actually manages assignments\nclass AssignmentRepository { ... } // stores trips\ninterface TripRepository { ... } // stores routes\nrecord TripDto(...) { } // serialised as \"route\" in json\nenum TripStatus { PLANNED, DISPATCHED, DONE } // route status in the API\n\nthe json field names are public API and cannot change; everything internal should line up with what the API calls things", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "vier Konfigurationsklassen, die alle dasselbe tun. Bitte zusammenführen, ohne Verhalten zu ändern:\n\n@ConfigurationProperties(\"solver\")\npublic record SolverProps(int timeLimitSeconds, int workers) {}\n\n@Component\npublic class SolverConfig {\n @Value(\"${solver.time-limit-seconds:30}\") int timeLimit;\n @Value(\"${solver.workers:4}\") int workers;\n}\n\npublic class SolverSettings {\n public static int timeLimit() { return Integer.parseInt(System.getenv().getOrDefault(\"SOLVER_TIME_LIMIT\", \"30\")); }\n}\n\n@ConfigurationProperties(\"fleet.solver\")\npublic record LegacySolverProps(Integer timeLimit, Integer workerCount) {}\n\nalle vier werden irgendwo im Code gelesen", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "de"}
{"prompt": "quarterly planning input from ops, i need a technical roadmap out of it:\n\n- two new customers in Q4, one with 900 vehicles across 11 depots, one with 40\n- the big one wants live ETA updates pushed to their own customer app\n- ops wants to stop doing manual reassignment when a vehicle breaks down\n- finance wants per-route cost, which we don't compute at all today\n- the solver team wants six weeks to finish the large-instance work or they'll keep firefighting\n- we lose one backend engineer to parental leave in October\n- the desktop app has to keep shipping monthly regardless", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, unassigned, and i want to think before someone picks it up:\n\nPLAT-204 — Split the monolith's dispatch module\nDispatch (assignment, driver state, notifications) shares a database and a deployment with planning (routes, solver jobs). Deploys of either block the other, and the assignment tables are the hottest thing in the database. The proposal on the table is a separate service with its own database and an event stream between them. Concerns raised so far: assignment reads join route data on every request; we have no event infrastructure; the mobile driver app talks to both; and there is one shared `tenants` table that everything reads.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "ML team's wishlist versus what we can actually run. sequence this for me:\n\n- retrain service-time model monthly instead of quarterly (needs a pipeline, currently a laptop job)\n- add traffic features from the new provider (contract signed, no integration)\n- online evaluation: compare predicted vs actual per fleet, alert on drift\n- move inference off the solver box (it's stealing CPU during solves)\n- a proper feature store, or at least stop recomputing features in three places\n- reproducible training runs — right now nobody can rebuild last quarter's model\n\ntwo ML engineers, one platform engineer at 50%", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "customer requirement doc, the part we haven't estimated:\n\n\"The System shall provide offline operation for the Planner desktop application. Planners must be able to view all routes for the current and following day, modify stop sequences, and reassign drivers while disconnected. Changes made offline must be reconciled automatically on reconnection with a clear indication of any conflict. The System shall retain at least 30 days of route history locally. Reconciliation must never silently discard a planner's change. The offline dataset shall not exceed 2 GB on disk.\"\n\nwe have none of this today and the contract is signed. i want the plan, the risks, and what we should push back on", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "ticket from design with the states enumerated, the sync indicator in the desktop titlebar:\n\nSync indicator\n- Idle: no icon, no text.\n- Syncing: 14px spinner, label \"Syncing…\" in secondary text, appears only after 400ms so quick syncs don't flash.\n- Offline: 14px cloud-slash icon, label \"Offline\", tooltip lists the number of pending changes.\n- Conflict: amber dot on the icon, label \"Needs attention\", clicking opens the conflict drawer.\n- Error: destructive icon, label \"Sync failed\", tooltip has the error and a Retry link.\n- Transitions between states fade over 150ms; the label width animates so the titlebar doesn't jump.\n- All states must be readable at 200% display scaling and must not rely on colour alone.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility ticket for the planner grid, from an actual customer complaint:\n\n\"Our dispatcher uses a screen reader and cannot use the planning grid at all. Tabbing moves focus into the grid and then it is trapped — arrow keys do nothing, and the only way out is to reload the page. Stop rows are announced as 'button' with no context. The delay column uses red and green only, which our colour-blind planner cannot distinguish. Drag and drop is the only way to reassign a stop, and there is no keyboard alternative.\"\n\nthe grid is our own component, `PlannerGrid.vue`, about 700 lines", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "モックの指示書です。配車画面の右パネルを実装してください:\n\n右パネル（幅 360px、折りたたみ可）\n- 見出しは「未割当の停車地」、件数をバッジで表示（0 件のときはバッジ非表示）。\n- 各行：住所（14px）、時間枠（12px、グレー）、右端に推定作業時間（12px）。行の高さ 56px、区切り線 1px、ホバーで背景 4%。\n- 行をドラッグするとタイムラインへ割当。ドラッグ中は行を 60% 不透明にし、ドロップ可能な車両バンドを 8% でハイライト。\n- 検索ボックスは上部に固定、入力から 200ms のデバウンス、住所・顧客名・伝票番号を対象。\n- 並び替え：時間枠が早い順 / 距離が近い順（トグル、既定は時間枠）。並び替えの状態は保存する。\n- 空状態：「未割当はありません」を中央にグレーで、上に 48px の余白。\n- パネルを折りたたむと 40px の縦タブになり、件数だけ表示。折りたたみ状態は次回起動時も維持。\n- 読み込み中：行のスケルトンを 6 件表示、スピナーは使わない。\n- エラー時：パネル上部に赤い帯で「読み込みに失敗しました」と再試行リンク（ダイアログは出さない）。\n- 200% の表示スケールでも文字が切れないこと。キーボードのみで行の選択と割当ができること。", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "ja"}
{"prompt": "partner spec for the ETA push they want, build our side:\n\nPOST to a URL they register, at most once every 30 seconds per route, only when the ETA moves by more than 2 minutes.\nbody: { route_id, vehicle_id, stops: [{ stop_id, eta, confidence, delay_minutes }], generated_at }\nauth: mutual TLS, their cert pinned; rotate without downtime twice a year\nretries: 3 attempts, exponential, then drop and count a metric — never queue indefinitely\nordering: they must be able to detect out-of-order delivery, so include a monotonically increasing sequence per route\nvolume: 900 vehicles, roughly 40 stops each, peak 08:00-10:00 local\nthey will disable the integration if we exceed 1 request per second sustained", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed in the design review, now needs building:\n\nCREATE TABLE route_costs (\n route_id uuid PRIMARY KEY REFERENCES routes(id) ON DELETE CASCADE,\n tenant_id uuid NOT NULL,\n distance_m bigint NOT NULL,\n drive_seconds bigint NOT NULL,\n service_seconds bigint NOT NULL,\n fuel_cents bigint NOT NULL,\n labour_cents bigint NOT NULL,\n toll_cents bigint NOT NULL DEFAULT 0,\n computed_at timestamptz NOT NULL,\n inputs_hash text NOT NULL\n);\n\ncosts are computed after a route is closed, from the vehicle's cost profile and the actual telemetry, and recomputed if telemetry arrives late. the recompute must be idempotent and must not fire the downstream reporting webhook twice for the same inputs_hash.", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "depot marker icon is the wrong asset", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "rustls to 0.23.14", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "csv export is missing the tenant column", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "matrix cache TTL back to 60 minutes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "el tooltip dice «kilometros», falta la tilde", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "es"}
{"prompt": "drop jupyterlab from the trainer image", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "lifecycle rule on the checkpoint bucket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "unused `watchEffect` import in RouteMap", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "boundary", "lang": "en"}
{"prompt": "teamId belongs in the notarize block", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "dead letter threshold from 3 to 10", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "Feature-Flag `live_eta` in Staging aktivieren", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "de"}
{"prompt": "a colleague's benchmark says the solver rewrite is a 65% improvement and the large-instance regression is \"a tuning issue\", and i'm not equipped to argue. look at the numbers and the code together and tell me whether the allocation explosion on big instances is inherent to the new approach or genuinely something we can tune away", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "our route map redraws every marker on every telemetry tick, which at 900 vehicles means the planner's fan spins up and the map stutters whenever anything moves. keep the visual result identical but only update what changed, and while you're in there the cluster expansion animation should not restart when an unrelated vehicle updates", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "the electron main process registers thirteen ipc handlers that each open with the same timing, try/catch and logging boilerplate, and two of them get the error shape subtly wrong so the renderer treats a failure as success. collapse them onto one registration helper with the current behaviour preserved, then make the two odd ones consistent with the rest", "purpose": "refactor", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "late stops should be hatched, not red", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "collapse the right panel to a tab", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "loss curves need a log-scale toggle", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "タイトルバーの同期アイコンを小さくして", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "ja"}
{"prompt": "delay column needs an icon too", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "timeline jumps when the label widens", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "`TripPlanner` should be `RoutePlanner`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "extract the guard clause from the handlers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "split build_features into steps", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "les quatre classes de config, une seule", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "fr"}
{"prompt": "pull the retry policy into one helper", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "inline `asLatLng`, single caller now", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "move the ipc handlers into one registrar", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "docstrings for the telemetry proto fields", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "release notes for desktop 2.9", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "kurzer Blogpost über die neue Routenansicht", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "de"}
{"prompt": "man page for `fleetctl solve`", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "document the 409 on /v1/assignments", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "changelog line for the ETA webhook", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "quién llama a `RouteService.close`?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "es"}
{"prompt": "safe to expose `force` to partners?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the claim TTL logic", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "does the shuffle buffer cross shards?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "ETAs drift after midnight UTC", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "warum verliert der Gateway alle 60s die Verbindung?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "de"}
{"prompt": "webhook endpoint for driver check-ins", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "design the cost pipeline, then build the writer", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "map out the offline story, then start on storage", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "back to the routing thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "unbreak it", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "proceed", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo de siempre con las rutas", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "es"}
{"prompt": "make the numbers look better", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick up the depot work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "another pass on the solver", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "whatever is quickest", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "次のスプリントの分、よろしく", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "ja"}
{"prompt": "tidy up before the demo", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "faz aquilo dos relatórios", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "pt"}
{"prompt": "one more look at this", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "live ETA push to a customer's own app is the thing that wins us the 900-vehicle account, and we've never pushed anything to anyone. i want to think through the transport, the fan-out, what we do when their endpoint is down for an hour, and how we avoid melting our own database recomputing ETAs every thirty seconds for forty thousand stops", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "per-route cost has been asked for by finance three quarters running and every time we discover another input we don't have — tolls, driver overtime bands, fuel prices that vary by depot, and vehicle depreciation that accounting computes differently from us. work out what a first version could honestly claim to measure, and what it would take to make it defensible", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "reproducibility of training runs is embarrassing: nobody can rebuild last quarter's model, the data snapshot isn't versioned, and the config that produced it lives in someone's shell history. lay out what we'd need — data versioning, run tracking, environment pinning — in an order where each step is useful on its own rather than a six-month platform project", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "breakdown reassignment is twenty minutes of manual work today and ops want it automatic, which sounds simple until you consider that stops have time windows, some drivers aren't certified for refrigerated loads, and the customer app has already told recipients an ETA. sketch how automatic reassignment should behave, including when it should refuse and ask a human", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "splitting dispatch out of the monolith keeps coming up and i want a position before the next architecture review. specifically: whether the shared tenants table is a blocker, what the event stream would need to guarantee, and whether we'd end up with a distributed monolith given how much assignment reads join route data", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "partners integrate against three endpoints and the only real documentation is a postman collection someone exported in 2024. write the integration guide: authentication, the assignment lifecycle, what each status means, idempotency, retry expectations, and a worked example from creating a route to receiving the completion webhook", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "solver has three strategies and the only place their differences are recorded is a comment that says \"guided is usually better\". document what each one does, when to use it, what the time limit means for each, and the fact that exhaustive is unusable past two hundred stops — for engineers, not for customers", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "telemetry ingest API is documented as \"see the proto file\", which is not documentation. write the reference: endpoint, auth, batching limits, what happens when the device clock is wrong, which fields are optional in practice versus in the schema, and the error codes with what a device should do about each", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "prospect's security team asked for our data flow documentation and we don't have any. from the code, work out what leaves our network — the geocoder, the traffic provider, the notification vendor — what fields go to each, and write it up in a form a security reviewer would accept", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "coordinate conversion helpers have drifted between the three packages and the desktop one rounds to six decimals on purpose, which nobody knew until today. consolidate them into the shared package with the rounding as an explicit option, update every call site, and keep the map SDK working exactly as it does now", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "nobody has been able to tell me what the solver does when two vehicles could serve the same stop at the same cost, and the tie-breaking matters for a customer who says their routes are non-deterministic. read the insertion and local-search code and explain the actual behaviour", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "gradle config aside, our CI is slow because the trainer image rebuilds torch every run, and i'd like both the diagnosis and the fix in one go — work out where the forty minutes actually goes, then restructure the workflow and the dockerfile so it's cached properly", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "we've agreed to do monthly retraining but not how, and the pipeline has to exist before october. i want the design for the whole loop first — data snapshot, training, evaluation gates, promotion — and then the snapshot step implemented so the data team can start using it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "desktop app needs an offline mode and the contract says so, but the shape isn't decided. think it through with me — what we cache, how conflicts surface to the planner, the 2GB budget — and then set up the local schema so the sync work can start behind it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "das Zusammenspiel von Solver und Queue ist nirgends beschrieben und gleichzeitig ziemlich verworren. Ich hätte gern erst ein Konzept, wie die Zuständigkeiten sauber getrennt wären, und danach den ersten Umbauschritt am Worker", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "de"}
{"prompt": "partner-facing docs and our actual API have drifted far enough that support answers questions by reading code. write the corrected reference for the three public endpoints, and fix the two response payloads where the API is genuinely wrong rather than the docs", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "runbook for a stuck solve queue is one line and the real procedure lives in two people's heads. write the proper page — the checks, the release command, when to escalate — and add the `queue peek --stuck` output format to the CLI docs while you're there", "purpose": "writing", "secondary": "backendImpl", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "escreve a documentação do endpoint de telemetria para os parceiros e, já agora, valida no código se os campos opcionais que documentamos são mesmo opcionais — desconfio que dois deles são obrigatórios na prática", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "pt"}
{"prompt": "ipc layer has thirteen near-identical handlers and no documentation of what a handler is allowed to do. collapse them into one registration helper, then write the short contributor note explaining how to add a new one", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like an honest read of whether our assignment endpoint is safe under concurrent dispatchers — the existsBy check followed by a save looks like a classic race — and if it is broken, the fix with a test that fails without it", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "there are two ways to construct a `Route` in the java service, a builder and a static factory, and half the code uses each", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "python package has utils.py, helpers.py and common.py, which between them contain forty functions and no organising principle", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "quick sanity check on the electron preload script before we ship it to customers who load a third-party map SDK in the renderer", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "someone should explain what our model actually predicts before the customer call tomorrow, in terms that survive a procurement questionnaire", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "is the coverage number we're about to report to management meaningful given that our two most incident-prone modules are at zero?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "what guarantees does our telemetry ingest actually make about ordering, and is that written down anywhere a partner could read?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "before i extend the assignment API, a plain description of what the `force` flag does today and which clients rely on it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "docs/architecture.md describes a synchronous solve that we replaced eighteen months ago, bring it in line with the queue-based flow", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "write the deprecation notice for the v0 telemetry endpoint, including the sunset date and what devices need to do", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "`--emit-intermediate` flag prints to stderr but the man page says stdout, and one of the two is wrong", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "vue linter complains about mutating the `stops` prop in two components, and in one of them it genuinely is a bug", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "vehicle band drag handler fires twice on trackpads, once from pointerup and once from click, and the stop lands in the wrong band", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we need a testing strategy for the solver that isn't \"run it and see\", given that outputs are heuristic and change with every tuning pass", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "multi-depot fleets that share vehicles on fridays can't be modelled at all today, and two customers now need it — what's the smallest data model change that makes it possible?", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns a route's cost breakdown, computed on read from the stored components, cached until the telemetry changes", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "driver check-in needs to record depot vs on-route state, from the mobile app's geofence events, with a manual override for the dispatcher", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "same solve job can be claimed twice if a worker's heartbeat is late, so claims need a fencing token rather than a TTL alone", "purpose": "backendImpl", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "you pick, something small", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "planner grid renders every vehicle band eagerly, so a fleet with 400 vehicles takes eleven seconds to open and then scrolls at about four frames a second on the machines our customers actually use, which are five-year-old windows laptops docked to two monitors. virtualise it, keep the drag-and-drop working across the virtualised boundary, and don't change how it looks at 40 vehicles", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "training dashboard is three matplotlib images regenerated by a cron job and pasted into a static page, which is why nobody looks at it. build it properly in the web app: loss and validation curves with a log-scale toggle, a run selector that can overlay two runs, hyperparameters in a side panel, and a link to the checkpoint in object storage", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "conflict drawer is a placeholder that says \"3 conflicts\" and nothing else, which is worse than useless to a planner deciding whether to keep their change or the server's. show each conflict as a field-level comparison with the two values, who made the other change and when, and a per-conflict choice, defaulting to nothing so an accidental click can't discard work", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "i've been asked to sign off on the assignment service before it goes to the customer with 900 vehicles, and my worry is what happens under concurrent dispatchers, but i also don't want to review it on vibes. go through the transaction boundaries, the existence check before save, the event publish and the notification call, and tell me which of those can leave inconsistent state", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "our data loader shuffles inside a buffer per worker, and validation loss has been suspiciously smooth for three weeks, which makes me think we're leaking ordering into the batches somehow. read the loader, the sharding and the sampler together and tell me whether the shuffle is doing what a person would assume from the name", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "there's a paragraph in the architecture doc about asynchronous solves that gets quoted in every design discussion, and i suspect at least half of it stopped being true when we removed the input hash in march. check each claim in it against the code and tell me which ones survive, because people are making decisions on this", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "assignment, route and trip are used interchangeably across the java service and mean different things depending on the file, with two of them exactly swapped relative to what the public API calls them. rename everything internal to match the API vocabulary, leave the serialised field names alone, and split it into commits a reviewer can actually follow", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "stop sequence numbers get recalculated in the planner grid, in the mapper that reads solver output, and again in the mobile app's local model, and the three implementations have quietly drifted, which is why a stop occasionally shows as number seven in one place and eight in another. one implementation, shared, with the current server behaviour as the reference", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "error responses across the API are a museum: the oldest endpoints return a bare string, the middle ones return `{\"error\": \"...\"}`, and the newest return problem details with a type URI. bring them all to the newest shape without changing a single status code, and keep the string form working for the two partners who parse it, behind a header if that's cleanest", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "feature construction exists three times — in the training script, in the offline evaluation script, and in the inference service — and they have drifted enough that a model scores differently depending on which path builds its inputs. bring them onto one implementation with the training version as the source of truth, and prove the other two produce identical outputs on a sample", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "deployment guide for the routing service stops at \"run the migration\" and says nothing about rollback, which matters because the last two rollbacks were improvised at two in the morning. write the full procedure including the pre-deploy checks, the migration order, what to do when the solver queue has in-flight claims, and how to roll back once the new schema has been written to", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "public status page lists three components with no descriptions and four incident severities that nobody can distinguish, so we've had customers escalate a degraded-performance notice as an outage. write the component descriptions and the severity definitions in language a fleet manager understands, with an example of what each severity feels like from their side", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "we're deprecating the v0 telemetry endpoint in six months and roughly 12,000 devices still use it, most of them on firmware we can't remotely update. write the deprecation notice for the docs, the email to fleet operators explaining what they need to do and by when, and the short internal note about which customers will need hand-holding", "purpose": "writing", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "the CLI's man page has been wrong since at least version 2: it documents `--emit-intermediate` as writing to stdout when the binary writes to stderr, it never mentions that exhaustive search is impractical past two hundred stops, and the default time limit changed last year. fix the page against the actual behaviour, and where the behaviour is the wrong one, say so rather than documenting the bug", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "health endpoint returns 200 whenever the process is up, which is how we managed to have a completely stalled solve queue for forty minutes while every dashboard was green. it should check the worker heartbeat and the queue depth, fail when nothing has been claimed in five minutes, and keep the response cheap enough to be hit every two seconds by the load balancer", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "a fleet reported that route costs were missing for three tenants after last tuesday's nightly run, and the job reported success, which means our error handling swallowed something. no alert fired, nothing in sentry, and the only trace is the absence of rows. work out how a tenant can be skipped silently and what the job would have to log for us to catch it next time", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "stop-level ETAs are recomputed on every read, which is fine at our current size and won't be once the ETA push exists, and separately the reporting team wants the history of what we predicted versus what happened. persist them with a sensible retention, keep reads fast, and think about whether history belongs in the same table before you write anything", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "how should the partner API be versioned once the ETA push exists? we have three endpoints in the wild, two partners who never upgrade anything, and a push integration where the version has to be negotiated rather than requested. i'd like a recommendation with the reasoning, plus what it means for the endpoints we already shipped without a version at all", "purpose": "planning", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "testing the solver is currently \"run it and look at the numbers\", which is why every tuning pass costs a week of nervous manual checking. i want a strategy that gives us confidence without pretending heuristic output is deterministic — golden instances with quality bounds, invariant checks, performance regression gates, whatever fits — and a view on what we'd run per commit versus nightly", "purpose": "planning", "secondary": "review", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt":"CalderaKiteSchedulerStore's FilterDrawer.vue needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Ist CalderaCinderAuthStore sicher?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"de"}
{"prompt":"What sequence would let CalderaOrbitSyncService adopt Swift 6 with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Two asks around CalderaDriftConsoleCoordinator: (1) separate CalderaDriftConsoleCoordinator's policy from transport without behavior changes; (2) capture the contract and rollback note for consumers. Do not introduce another runtime dependency, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Renderer: Ticket OPS-43138: retire the legacy replay path for CalderaBeaconStoreFlow\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 CalderaBeaconStoreFlow 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":"CalderaWrenExportCoordinator: give it a nicer flow","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaAmberFilterStore's staging timeout is already known to be wrong: change the single projects/caldera/Sources/App/SessionStore.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":"Indexer: The CalderaCedarPolicyStore empty state in projects/caldera/web/components/FilterDrawer.vue needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-43123\n\n08:02 deploy CalderaBasilRunnerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current CalderaBasilRunnerFlow 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":"Architect a gradual ownership transfer for CalderaFernSnapshotStore across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"// projects/caldera/cmd/exporter/main.py\nfinal class CalderaSableParserFlowCoordinator {\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 CalderaSableParserFlow; 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":"Cadre la migration de CalderaDriftConsoleStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"fr"}
{"prompt":"Apparently: diff --git a/projects/caldera/cmd/exporter/main.py b/projects/caldera/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/cmd/exporter/main.py\n+++ b/projects/caldera/cmd/exporter/main.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is CalderaHarborIndexCoordinator's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Fresh release brief for CalderaNimbusFormCoordinator:\n- primary outcome: assess ownership and failure handling in projects/caldera/packages/api/openapi.yaml\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/caldera/packages/api/openapi.yaml\n- platform constraint: gRPC\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.8,"slice":"mixed","lang":"en"}
{"prompt":"CalderaBirchMigratorCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Lately: We expect CalderaMoonlitSDKStore to outgrow its current FastAPI arrangement next quarter, but changing everything at once would be risky. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing FastAPI deployment\n- keep the work scoped to CalderaMoonlitSDKStore and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"I inherited CalderaPrismCacheService and need a careful read of projects/caldera/crates/index/src/segment.rs before I can sign off on the next release. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing gRPC deployment\n- keep the work scoped to CalderaPrismCacheService and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Corrige le timeout de CalderaCinderAuthService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"fr"}
{"prompt":"CalderaBeaconStoreService's staging timeout is already known to be wrong: change the single projects/caldera/engine/render/atlas.cpp value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"The destination for CalderaGarnetModalStore is broadly agreed; the missing piece is a reversible route from projects/caldera/ui/settings/PrivacyPane.tsx to that target. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaGarnetModalStore\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Support wants the behavior in projects/caldera/ml/pipeline/features.py recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"One contained cleanup in projects/caldera/cmd/exporter/main.py: remove the obsolete CalderaHarborIndexStore import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: CalderaRavenSessionStore works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaRavenSessionStore\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-43155: finish the compact CalderaCraneWorkspaceCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/caldera/config/staging.toml\nFramework: gRPC\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 CalderaCraneWorkspaceCoordinator'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":"projects/caldera/config/staging.toml 里的 CalderaIrisBatchService 最近在 gRPC 流程中出现间歇性问题。 请写一份面向调用方的说明，包含 contract、错误、retry 和可复制示例，不要改 handler。\n\n约束：\n- 继续使用 gRPC\n- 保持兼容性和取消语义\n- 改动只限于 CalderaIrisBatchService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"zh"}
{"prompt":"This should remain a deliberately small patch: CalderaHarborIndexService has one known configuration mistake in projects/caldera/ml/pipeline/features.py, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing OpenTelemetry deployment\n- keep the work scoped to CalderaHarborIndexService and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"CalderaFernSnapshotCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"For CalderaEchoRegistryCoordinator, separate CalderaEchoRegistryCoordinator's policy from transport without behavior changes; once that is complete, give the existing implementation a read-only safety pass. Work from projects/caldera/Sources/CLI/Commands/Doctor.swift, stay with OpenTelemetry, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"CalderaSlateEditorCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaCinderAuthCoordinator: restructure, then correct","purpose":"refactor","secondary":"backendImpl","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"CalderaBeaconStoreCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaOrbitSyncCoordinator: sort out the rough edge","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"# CI job 43116: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: OpenTelemetry\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] CalderaRavenSessionFlowIntegration.replays_after_timeout ... ok\n[test] CalderaRavenSessionFlowIntegration.cancels_orphaned_batch ... FAILED\n\nExpected:\n pending_jobs{queue=\"replay\"} 0\nActual:\n pending_jobs{queue=\"replay\"} 1\n\nCaptured spans:\n batch.receive 2.1ms status=ok\n storage.transaction 44.8ms status=cancelled\n batch.nack <missing>\n\nteardown warning: resource still in use: redis connection pool (1 borrower)\nretry 1/2 with identical seed ... passed\nretry 2/2 with identical seed ... passed\n\nThe failure began after the test suite was sharded, but it sometimes appears on an unsharded nightly run. There are no wall-clock sleeps in this test; it advances the fake scheduler until idle.\n\nWire CalderaRavenSessionFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/caldera/lib/codec/frame.cc b/projects/caldera/lib/codec/frame.cc\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/lib/codec/frame.cc\n+++ b/projects/caldera/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\nRestructure CalderaPineMetricsFlow 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":"Split projects/caldera/services/ledger/replay.go by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The behavior of CalderaCraneWorkspaceService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/caldera/packages/api/openapi.yaml. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current gRPC operational envelope\n\nThis repository spans embedded, Go services, Android; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"En projects/caldera/ui/settings/PrivacyPane.tsx, CalderaAsterWebhookService tiene un problema intermitente en el flujo de Room. 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 Room\n- conservar compatibilidad y cancelación\n- limitar el cambio a CalderaAsterWebhookService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"es"}
{"prompt":"Oddly: diff --git a/projects/caldera/packages/api/openapi.yaml b/projects/caldera/packages/api/openapi.yaml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/packages/api/openapi.yaml\n+++ b/projects/caldera/packages/api/openapi.yaml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Read the artifact above as a skeptical reviewer. Is CalderaFernSnapshotFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Currently: projects/caldera/ml/pipeline/features.py の CalderaHarborIndexFlow で、OpenTelemetry の flow に断続的な問題が起きています。 responsive layout、empty/retry state、keyboard focus、dark mode、reduced motion を仕上げてください。\n\n制約:\n- OpenTelemetry を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は CalderaHarborIndexFlow のみ","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Test Suite 'CalderaPrismCacheFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[CalderaPrismCacheFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/caldera/crates/index/src/segment.rs:144: error: -[CalderaPrismCacheFlowTests 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 '-[CalderaPrismCacheFlowTests 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 CalderaPrismCacheFlow'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":"Compare the old and new CalderaCraneWorkspaceStore 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":"CalderaCedarPolicyCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Today: Is there a cleaner way to separate CalderaCraneWorkspaceFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Dedupe CalderaKiteSchedulerService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Support wants the behavior in projects/caldera/apps/console/routes/usage.svelte recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"# CI job 43122: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Swift 6\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] CalderaSpruceDaemonFlowIntegration.replays_after_timeout ... ok\n[test] CalderaSpruceDaemonFlowIntegration.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 CalderaSpruceDaemonFlow 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":"Architect a gradual ownership transfer for CalderaOpalRouterFlow across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"CalderaPrismCacheCoordinator is blocking the next release because a misleading timeout name used in five packages. I need two concrete outcomes from a single pass: ship the idempotent CalderaPrismCacheCoordinator replay endpoint, and capture the contract and rollback note for consumers. Use the existing gRPC conventions in projects/caldera/pkg/cache/lease.rs; 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":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"CalderaWillowCodecCoordinator needs a paired pass: produce a consumer guide for CalderaWillowCodecCoordinator, plus give the existing implementation a read-only safety pass. Use projects/caldera/config/staging.toml as the source of truth, preserve the gRPC contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Two deliverables are holding up CalderaSableParserCoordinator. First, separate CalderaSableParserCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/caldera/ml/pipeline/features.py, which follows OpenTelemetry conventions and currently suffers from stale cursors when a page is resumed. 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":"refactor","secondary":"review","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"CalderaJuniperCLICoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"PM is preparing the CalderaTideWorkerService rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaTideWorkerService\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Context: The data is already available in projects/caldera/internal/auth/refresh.go; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"A flaky failure around CalderaDeltaCanvasService survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaDeltaCanvasService\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Why does CalderaOpalRouterStore's Swift 6 worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Background: projects/caldera/src/sync/reconcile.ts now contains CalderaQuartzPlayerStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Collapse the CalderaMosaicGridStore wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Question: The behavior of CalderaNovaPickerService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/caldera/lib/codec/frame.cc. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current Room operational envelope\n\nThis repository spans embedded, Go services, Android; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Design handed over a final pass for CalderaCloudReconcilerService, and the basic data flow in projects/caldera/internal/auth/refresh.go already works. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing FastAPI deployment\n- keep the work scoped to CalderaCloudReconcilerService and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Does CalderaEmberRelayStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/caldera/crates/index/src/segment.rs, 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":"Introduce a durable deduplication key for CalderaBeaconStoreStore events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"# projects/caldera/src/sync/reconcile.ts\n[worker.calderasummitproxyflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.calderasummitproxyflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.calderasummitproxyflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.CalderaSummitProxyFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-43132\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/caldera/src/sync/reconcile.ts. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Observation: The first CalderaAcornWidgetStore request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Constraint: # projects/caldera/workers/thumbnail/consumer.ex\n[worker.calderagarnetmodalflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.calderagarnetmodalflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.calderagarnetmodalflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.CalderaGarnetModalFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-43113\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Align CalderaGarnetModalFlow'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":"Two asks around CalderaMosaicGridCoordinator: (1) produce a consumer guide for CalderaMosaicGridCoordinator; (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":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"CalderaSpruceDaemonCoordinator: restructure, then correct","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Clarify CalderaSpruceDaemonService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"CalderaFrostPanelCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-43136: retire the legacy replay path for CalderaAmberFilterFlow\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 CalderaAmberFilterFlow 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":"Request: # projects/caldera/pkg/cache/lease.rs\n[worker.calderawrenexportflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.calderawrenexportflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.calderawrenexportflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.CalderaWrenExportFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-43140\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 CalderaWrenExportFlow'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":"For CalderaSummitProxyCoordinator, ship the idempotent CalderaSummitProxyCoordinator replay endpoint; once that is complete, give the existing implementation a read-only safety pass. Work from projects/caldera/db/migrations/20260730_events.sql, stay with Swift 6, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"backendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"CalderaMarbleTokenCoordinator needs a paired pass: lay out a staged migration for CalderaMarbleTokenCoordinator, plus consolidate the duplicated normalization paths without changing behavior. Use projects/caldera/ml/pipeline/features.py as the source of truth, preserve the OpenTelemetry contract, and avoid unrelated cleanup.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"CalderaRainfallDBStore needs an idempotent replay endpoint backed by gRPC; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The CalderaCoralUploadService empty state in projects/caldera/web/components/FilterDrawer.vue needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for CalderaDeltaCanvasCoordinator:\n- primary outcome: separate CalderaDeltaCanvasCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/caldera/db/migrations/20260730_events.sql\n- platform constraint: Swift 6\n- known complication: cancellation being swallowed at the repository boundary\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":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"projects/caldera/workers/thumbnail/consumer.ex 里的 CalderaFrostPanelStore 最近在 Room 流程中出现间歇性问题。 请写一份面向调用方的说明，包含 contract、错误、retry 和可复制示例，不要改 handler。\n\n约束：\n- 继续使用 Room\n- 保持兼容性和取消语义\n- 改动只限于 CalderaFrostPanelStore","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"zh"}
{"prompt":"Why is CalderaLumenChartStore stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Outline a safer CalderaFlintTimelineService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Rename CalderaSummitProxyService's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"Incident timeline — INC-43131\n\n08:02 deploy CalderaMarbleTokenFlow 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 CalderaMarbleTokenFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Split CalderaBirchMigratorStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Decouple CalderaSummitProxyStore's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Clarify CalderaMapleQueueStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Give CalderaAsterWebhookStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale CalderaNimbusFormStore value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current gRPC operational envelope\n\nThis repository spans embedded, Go services, Android; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Trace CalderaMarbleTokenService's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"CalderaMapleQueueCoordinator needs a paired pass: finish CalderaMapleQueueCoordinator's responsive empty and retry states, plus capture the contract and rollback note for consumers. Use projects/caldera/engine/render/atlas.cpp as the source of truth, preserve the Room contract, and avoid unrelated cleanup.","purpose":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about CalderaGarnetModalService, but the current prose in projects/caldera/workers/thumbnail/consumer.ex only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing Room deployment\n- keep the work scoped to CalderaGarnetModalService and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"We expect CalderaFlintTimelineStore to outgrow its current Swift 6 arrangement next quarter, but changing everything at once would be risky. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to CalderaFlintTimelineStore and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Pin CalderaBasilRunnerStore's Room dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-43154: retire the legacy replay path for CalderaCloudReconcilerCoordinator\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 CalderaCloudReconcilerCoordinator 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":"Store CalderaMapleQueueService's delivery receipts","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-43115\n\n08:02 deploy CalderaNimbusFormFlow 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 CalderaNimbusFormFlow 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":"Sequence CalderaBasilRunnerService's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Map CalderaEchoRegistryService's ownership split","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Goal: Two asks around CalderaEmberRelayCoordinator: (1) change CalderaEmberRelayCoordinator's known staging timeout from 15 to 30 seconds; (2) capture the contract and rollback note for consumers. Do not introduce another runtime dependency, and leave a clear boundary between the resulting artifacts or edits.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/caldera/src/sync/reconcile.ts b/projects/caldera/src/sync/reconcile.ts\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/src/sync/reconcile.ts\n+++ b/projects/caldera/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 CalderaDeltaCanvasFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Test Suite 'CalderaLumenChartFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[CalderaLumenChartFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/caldera/pkg/cache/lease.rs:144: error: -[CalderaLumenChartFlowTests 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 '-[CalderaLumenChartFlowTests 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\nBring CalderaLumenChartFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Does CalderaLedgerGateStore 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":"CalderaAmberFilterCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaQuartzPlayerCoordinator: could this be clearer","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaPineMetricsCoordinator: polish the last piece","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Bump CalderaMoonlitSDKService's timeout to 30s","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Symptom: // projects/caldera/infra/modules/edge/main.tf\nfinal class CalderaMoonlitSDKFlowCoordinator {\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 CalderaMoonlitSDKFlow; 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":"Pin CalderaWillowCodecService's gRPC dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up CalderaMoonlitSDKCoordinator. First, change CalderaMoonlitSDKCoordinator's known staging timeout from 15 to 30 seconds. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/caldera/internal/auth/refresh.go, which follows FastAPI 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":"quickFix","secondary":"debugging","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"The first CalderaOspreyJobFlow request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"How should CalderaSpruceDaemonStore be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_43121'\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_43121'::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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Determine why CalderaBirchMigratorFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Give CalderaNimbusFormService a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Headsup: Ticket OPS-43158: retire the legacy replay path for CalderaNovaPickerCoordinator\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 CalderaNovaPickerCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"What does CalderaMosaicGridService own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"CalderaLedgerGateCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"projects/caldera/apps/console/routes/usage.svelte has grown through several launches, and CalderaOpalRouterService now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to CalderaOpalRouterService and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind CalderaTideWorkerFlow's OpenTelemetry choices be captured as an ADR for engineers joining the project next quarter? 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":"Read projects/caldera/engine/render/atlas.cpp and tell me whether CalderaPineMetricsStore 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":"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_43149'\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_43149'::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\nReconstruct the CalderaCedarPolicyFlow 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":"Em projects/caldera/packages/api/openapi.yaml, o CalderaIrisBatchStore tem um problema intermitente no fluxo de gRPC. Leia o fluxo atual e avalie ownership, cancelamento e ordem; preciso apenas da análise.\n\nRestrições:\n- continuar com gRPC\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao CalderaIrisBatchStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"FYI: # projects/caldera/services/ledger/replay.go\n[worker.calderakiteschedulerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.calderakiteschedulerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.calderakiteschedulerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.CalderaKiteSchedulerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-43129\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. Make the one confirmed configuration correction in projects/caldera/services/ledger/replay.go. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"In projects/caldera/cmd/exporter/main.py hat CalderaSableParserService ein sporadisches Problem im OpenTelemetry-Ablauf. Trenne Verantwortlichkeiten und entferne Duplikate, ohne API, Wire-Werte, Reihenfolge oder sichtbares Verhalten zu ändern.\n\nRandbedingungen:\n- OpenTelemetry weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf CalderaSableParserService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um CalderaSableParserService mit OpenTelemetry kompatibel.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"CalderaAtlasSearchCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaPineMetricsService 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.6,"slice":"core","lang":"en"}
{"prompt":"Match CalderaVelaDrawerStore's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"# CI job 43143: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Room\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] CalderaFrostPanelFlowIntegration.replays_after_timeout ... ok\n[test] CalderaFrostPanelFlowIntegration.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 CalderaFrostPanelFlow 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":"Clarify CalderaVelaDrawerService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"Please turn CalderaJuniperCLIStore's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code. 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":"CalderaMicaProfileCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Meanwhile: Incident timeline — INC-43159\n\n08:02 deploy CalderaOspreyJobCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the CalderaOspreyJobCoordinator decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-43146: retire the legacy replay path for CalderaLedgerGateFlow\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 CalderaLedgerGateFlow 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":"Set CalderaEchoRegistryStore's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"CalderaDriftConsoleService é seguro?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"pt"}
{"prompt":"Two asks around CalderaVelaDrawerCoordinator: (1) assess ownership and failure handling in projects/caldera/pkg/cache/lease.rs; (2) capture the contract and rollback note for consumers. Do not introduce another runtime dependency, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Production says CalderaOspreyJobStore is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. 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- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current FastAPI operational envelope\n\nThis repository spans embedded, Go services, Android; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"projects/caldera/engine/render/atlas.cpp has grown through several launches, and CalderaNovaPickerStore now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- do not introduce another runtime dependency\n- stay compatible with the existing Room deployment\n- keep the work scoped to CalderaNovaPickerStore and its direct tests\n\nThe relevant code crosses embedded, Go services, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"CalderaLumenChartCoordinator: sequence, then polish","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"CalderaCoralUploadCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"The name pendingAck means two different things across CalderaAtlasSearchService's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Read projects/caldera/Sources/CLI/Commands/Doctor.swift and tell me whether CalderaTideWorkerStore 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":"Any races in CalderaMicaProfileStore?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-43125\n\n08:02 deploy CalderaWillowCodecFlow 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 CalderaWillowCodecFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Bring CalderaAsterWebhookFlow'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":"Locally: 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_43135'\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_43135'::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\nFind the source of this CalderaIrisBatchFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Set CalderaLumenChartService's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-43117\n\n08:02 deploy CalderaFlintTimelineFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current CalderaFlintTimelineFlow 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":"Add a bounded CalderaNovaPickerFlow 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":"Ticket OPS-43137: retire the legacy replay path for CalderaOrbitSyncFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Assess CalderaOrbitSyncFlow 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":"CalderaFlintTimelineCoordinator: correct, then assess","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Production: Incident timeline — INC-43119\n\n08:02 deploy CalderaCinderAuthFlow 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 CalderaCinderAuthFlow 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":"Staging: The data is already available in projects/caldera/Sources/CLI/Commands/Doctor.swift; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"CI: Incident timeline — INC-43147\n\n08:02 deploy CalderaJuniperCLIFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the CalderaJuniperCLIFlow 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":"Atlas: Incident timeline — INC-43130\n\n08:02 deploy CalderaVelaDrawerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why CalderaVelaDrawerFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Test Suite 'CalderaEmberRelayFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[CalderaEmberRelayFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/caldera/internal/auth/refresh.go:144: error: -[CalderaEmberRelayFlowTests 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 '-[CalderaEmberRelayFlowTests 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\nFinish the visible CalderaEmberRelayFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current CalderaOspreyJobService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaOspreyJobService\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Ownership of CalderaCopperBridgeService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current Swift 6 operational envelope\n\nThis repository spans embedded, Go services, Android; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"CalderaCloudReconcilerFlow's staging timeout is already known to be wrong: change the single projects/caldera/internal/auth/refresh.go value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"CalderaAcornWidgetCoordinator: handle the lingering thing","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"How does CalderaFernSnapshotService propagate cancellation through the gRPC boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"The name pendingAck means two different things across CalderaLedgerGateService's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"CalderaBasilRunnerCoordinator: polish, then correct","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Could CalderaCopperBridgeStore show the active Swift 6 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":"Before touching projects/caldera/db/migrations/20260730_events.sql, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/caldera/crates/index/src/segment.rs b/projects/caldera/crates/index/src/segment.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/crates/index/src/segment.rs\n+++ b/projects/caldera/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 CalderaRainfallDBCoordinator by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"2026-07-30T08:14:11.409Z level=info service=calderacoraluploadflow pod=calderacoraluploadflow-7cf8 request_id=43139 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=calderacoraluploadflow request_id=43139 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=calderacoraluploadflow request_id=43139 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=calderacoraluploadflow request_id=43139 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=calderacoraluploadflow request_id=43139 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=calderacoraluploadflow request_id=43139 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=calderacoraluploadflow request_id=43139 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=calderacoraluploadflow request_id=43139 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\nDetermine why CalderaCoralUploadFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"CalderaGarnetModalCoordinator is blocking the next release because a feature flag whose default differs between environments. I need two concrete outcomes from a single pass: change CalderaGarnetModalCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing Room conventions in projects/caldera/ui/settings/PrivacyPane.tsx; 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.5,"slice":"mixed","lang":"en"}
{"prompt":"Three teams extended CalderaDeltaCanvasStore independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Separate those responsibilities into focused units, remove the duplicated normalization branches, and keep public types, wire values, log fields, timing, and test-observable behavior exactly the same.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- do not introduce another runtime dependency\n- retain the current Swift 6 operational envelope\n\nThis repository spans embedded, Go services, Android; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Extract CalderaMarbleTokenStore's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Drop CalderaRavenSessionService's unused import","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for CalderaBirchMigratorService","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Beacon: Ticket OPS-43134: retire the legacy replay path for CalderaAtlasSearchFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible CalderaAtlasSearchFlow 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":"For CalderaKiteSchedulerCoordinator, produce a consumer guide for CalderaKiteSchedulerCoordinator; once that is complete, correct the known stale timeout beside it. Work from projects/caldera/web/components/FilterDrawer.vue, stay with FastAPI, and do not introduce another runtime dependency. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current CalderaRainfallDBService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaRainfallDBService\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Draft CalderaMicaProfileService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"// projects/caldera/Sources/App/SessionStore.swift\nfinal class CalderaEchoRegistryFlowCoordinator {\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 CalderaEchoRegistryFlow; 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":"Support wants the behavior in projects/caldera/services/ledger/replay.go 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":"Cinder: // projects/caldera/ml/pipeline/features.py\nfinal class CalderaAcornWidgetFlowCoordinator {\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 CalderaAcornWidgetFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"En projects/caldera/ml/pipeline/features.py, CalderaSableParserStore tiene un problema intermitente en el flujo de OpenTelemetry. Termina el layout responsive, estados vacío y retry, foco por teclado, dark mode y reduced motion.\n\nRestricciones:\n- seguir con OpenTelemetry\n- conservar compatibilidad y cancelación\n- limitar el cambio a CalderaSableParserStore","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"es"}
{"prompt":"Delta: projects/caldera/ui/settings/PrivacyPane.tsx の CalderaFrostPanelService で、Room の flow に断続的な問題が起きています。 queue、scheduler、cancel 経路を追い、仮説を比較して、変更前に原因を特定してください。\n\n制約:\n- Room を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は CalderaFrostPanelService のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Ember: The minimum supported FastAPI version in projects/caldera/infra/modules/edge/main.tf 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":"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_43156'\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_43156'::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\nFind the source of this CalderaTideWorkerCoordinator symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Frost: The API work is done; what remains for CalderaPrismCacheStore is the visible interaction layer across loading, offline, empty, and success cases. Bring the drawer and detail pane to production polish with fluid sizing, honest skeletons, focus restoration, accessible announcements, and touch targets that survive large text.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside CalderaPrismCacheStore\n- do not introduce another runtime dependency\n\nSeveral teams work in this embedded, Go services, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Where did CalderaWillowCodecStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Read projects/caldera/internal/auth/refresh.go and tell me whether CalderaSlateEditorService can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/caldera/engine/render/atlas.cpp b/projects/caldera/engine/render/atlas.cpp\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/engine/render/atlas.cpp\n+++ b/projects/caldera/engine/render/atlas.cpp\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is CalderaMicaProfileFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Garnet: The CalderaRainfallDBFlow 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":"Harbor: diff --git a/projects/caldera/lib/codec/frame.cc b/projects/caldera/lib/codec/frame.cc\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/lib/codec/frame.cc\n+++ b/projects/caldera/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\nWire CalderaMapleQueueFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"// projects/caldera/internal/auth/refresh.go\nfinal class CalderaSlateEditorFlowCoordinator {\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 CalderaSlateEditorFlow; 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":"Serve CalderaEmberRelayService health checks","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a CalderaQuartzPlayerService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"What is the safest way to split projects/caldera/apps/console/routes/usage.svelte into independently owned modules while CalderaOrbitSyncStore's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Iris: diff --git a/projects/caldera/db/migrations/20260730_events.sql b/projects/caldera/db/migrations/20260730_events.sql\nindex 62d71aa..90f3c1e 100644\n--- a/projects/caldera/db/migrations/20260730_events.sql\n+++ b/projects/caldera/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\nRestructure CalderaQuartzPlayerFlow 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":"UI ticket DES-43127: finish the compact CalderaDriftConsoleFlow filter experience\n\nRoute: /catalog/search\nSource: projects/caldera/apps/console/routes/usage.svelte\nFramework: Swift 6\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible CalderaDriftConsoleFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"CalderaIrisBatchCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-43153\n\n08:02 deploy CalderaAsterWebhookCoordinator 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 を維持し、根拠と判断を明確にしてください。 Capture the CalderaAsterWebhookCoordinator decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-43152: retire the legacy replay path for CalderaCopperBridgeCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible CalderaCopperBridgeCoordinator rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Could CalderaWrenExportService show the active gRPC sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/caldera/workers/thumbnail/consumer.ex: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: calderamosaicgridflow::scheduler::LeaseTask::flush\n at ./projects/caldera/workers/thumbnail/consumer.ex:217:18\n 4: calderamosaicgridflow::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\nDetermine why CalderaMosaicGridFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Juniper: // projects/caldera/app/src/main/SyncWorker.kt\nfinal class CalderaOpalRouterCoordinatorCoordinator {\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 CalderaOpalRouterCoordinator 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":"CalderaRavenSessionCoordinator: restructure, then correct","purpose":"refactor","secondary":"backendImpl","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Before we approve CalderaSlateEditorStore, assess whether two validators with subtly different error strings is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
data/round2-04.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "our changelog needs an entry for the removal of `wal_sync: never`, with the migration advice for anyone using it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "the events panel in the admin console refreshes every ten seconds by replacing the whole list, which resets the scroll position and makes it useless during an incident when you're trying to read something. keep the polling but merge new events in without moving what the user is looking at, and show a \"3 new events\" pill when they're scrolled away from the top", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "message ordering guarantee we advertise, and the code that's meant to implement it. do they match?\n\ndocs: \"Messages within a thread are delivered to all devices in the order the server accepted them. Across threads, no ordering is guaranteed.\"\n\n// fanout.go\nfunc (f *Fanout) Publish(ctx context.Context, m Message) error {\n\tdevices, err := f.devices.For(ctx, m.ThreadID)\n\tif err != nil { return err }\n\tvar g errgroup.Group\n\tfor _, d := range devices {\n\t\td := d\n\t\tg.Go(func() error { return f.push.Send(ctx, d, m) })\n\t}\n\treturn g.Wait()\n}\n\n// accept path assigns m.ServerTS = time.Now() before enqueueing to a per-shard channel", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "our health endpoint counts a stalled compaction as healthy, so nothing pages until customers notice", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "the reply bar's offline behaviour is currently that everything looks normal until you background the app and the message vanishes, which is the worst possible outcome. sent-but-unacknowledged messages should show a clock glyph, failed ones a retry affordance, and the bar itself should never lie about whether something has been delivered", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "is this actually a race or am i misreading the memory ordering?\n\nstd::atomic<uint64_t> latest_lsn_{0};\n\nvoid WalWriter::Append(const Record& r) {\n auto lsn = next_lsn_.fetch_add(1, std::memory_order_relaxed);\n buffer_->Write(lsn, r);\n latest_lsn_.store(lsn, std::memory_order_release);\n}\n\nuint64_t WalWriter::Durable() const {\n return latest_lsn_.load(std::memory_order_acquire);\n}\n\nbool Reader::Visible(uint64_t lsn) const {\n return lsn <= writer_->Durable();\n}\n\nfour writer threads share one WalWriter, readers call Visible on their own threads", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "a customer's engineer sent this and support forwarded it to me. answer it as a docs page rather than an email:\n\n\"We're running the operator in a cluster with a strict pod security admission policy (restricted). Your StatefulSet requests runAsUser: 0 and a hostPort, both of which are rejected. Is running as root actually required? Is the hostPort required, or is it there because of the old deployment model? We'd also like to know the minimum RBAC the operator needs — the ClusterRole in your chart grants * on everything, which our security team will not approve.\"", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "design review ticket, i want the thinking done before the meeting:\n\nLUM-460 — Read-your-writes without pinning reads to the leader\nToday a client that needs to read its own write sends `X-Read-Your-Writes` and we route to the leader, which is why the leader is 70% of read traffic on chatty threads. Proposal is per-client LSN tracking with follower reads that wait for the LSN, bounded by a timeout after which we fall back to the leader. Concerns: clients are mobile and reconnect constantly; LSN would have to survive a reconnect; a slow follower could hold a request for the whole timeout; we have no way to observe per-client staleness today.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "support ticket volumes for the last quarter, by category. what would you fix first and why:\n\n retention misconfiguration 182 tickets avg 41 min to resolve\n push registration failures 141 tickets avg 88 min\n pod evictions / storage 96 tickets avg 130 min\n upgrade gone wrong 44 tickets avg 4.2 hours\n \"messages out of order\" 38 tickets avg 2.1 hours, 12 unresolved\n RBAC / install problems 31 tickets avg 55 min\n everything else 77 tickets\n\nengineering capacity for this is about one person for a quarter, and support is asking for docs rather than fixes on at least half of these", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "we need the spool rotation the incident asked for. current behaviour and the requirement:\n\n- broker appends every unacknowledged message to /tmp/spool/<shard>.log, no rotation, no cap\n- on restart the whole spool is replayed in order; the file has reached 41GB on a busy shard\n- required: rotate at 2GB, keep at most 4 segments per shard, drop the oldest with a loud metric and a warning log\n- replay must still be in order across segments, and must skip segments whose checksum fails rather than crashing\n- the operator sets the cap via `tuning.spool_max_mb`, defaulting to 8192 total per shard\n- none of this may block the write path, which currently appends synchronously", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "message bubbles clip at large type sizes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "operator reconcile loop is hot-looping and i can't see why from the logs:\n\nI0729 11:02:14.881 1 controller.go:212] \"Reconciling\" cluster=\"lumen-prod\" generation=41 observedGeneration=41\nI0729 11:02:14.902 1 status.go:88] \"Updating status\" phase=\"Ready\" replicas=3 readyReplicas=3\nI0729 11:02:14.918 1 controller.go:212] \"Reconciling\" cluster=\"lumen-prod\" generation=41 observedGeneration=41\nI0729 11:02:14.941 1 status.go:88] \"Updating status\" phase=\"Ready\" replicas=3 readyReplicas=3\nI0729 11:02:14.958 1 controller.go:212] \"Reconciling\" cluster=\"lumen-prod\" generation=41 observedGeneration=41\nW0729 11:02:15.002 1 reflector.go:539] watch of *v1alpha1.MessageCluster ended with: too old resource version\nI0729 11:02:15.021 1 controller.go:212] \"Reconciling\" cluster=\"lumen-prod\" generation=41 observedGeneration=41\n\nabout 60 reconciles a second, CPU pinned, nothing in the cluster is actually changing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "push notifications stopped for ios users on tuesday, apns feedback:\n\n{\"reason\":\"BadDeviceToken\",\"timestamp\":1753843201} count=41221\n{\"reason\":\"Unregistered\",\"timestamp\":1753843261} count=8814\n{\"reason\":\"TopicDisallowed\"} count=2201\n{\"reason\":\"ExpiredProviderToken\"} count=1\n\nour side:\n push_send_total{result=\"error\"} 52,236 in 24h\n push_send_total{result=\"ok\"} 1,102 in 24h\n last successful send: 2026-07-27T23:58:02Z\n\nwe did rotate the signing key on monday but the ExpiredProviderToken count is 1, not 52 thousand", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "go vet after the operator refactor, all in one file:\n\n./internal/controller/cluster_controller.go:88:2: loop variable c captured by func literal\n./internal/controller/cluster_controller.go:141:12: the cancel function returned by context.WithTimeout should be called, not discarded, to avoid a context leak\n./internal/controller/cluster_controller.go:212:5: unreachable code\n./internal/controller/status.go:41:9: result of fmt.Sprintf call not used\n\nvet: exit status 1\nmake: *** [Makefile:22: vet] Error 1", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "one timestamp helper, not three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "what does `wal_sync: batch` promise? write it down", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "why does compaction stall at 12%?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "thread screen has eleven hardcoded colours and three magic paddings; move it onto the design tokens without changing how it looks", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "design handoff for the thread screen's reply bar, react native:\n\nReply bar\n- Pinned to the keyboard, 52pt minimum height, grows to 5 lines then scrolls internally.\n- Leading: attach button 32pt, tinted secondary; long-press opens the media sheet.\n- Text input: 16pt, placeholder \"Message\", no border, 8pt vertical padding.\n- Trailing: send button appears only when there's text, 28pt circle, scales in over 120ms.\n- Reply-to state: a 40pt strip above the input with a 2pt accent bar, the quoted text truncated to one line, and an X to clear.\n- Typing indicator sits above the bar, fades in after 400ms of a peer typing, out after 3s of silence.\n- Safe area: the bar must sit above the home indicator, and the keyboard animation must not cause a jump on iOS 18.\n- Offline: the bar stays usable, sent messages show a clock glyph until acknowledged.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "is our eviction fallback safe?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "support burden is dominated by three things — retention misconfiguration, push registration failures and pod evictions — and support keeps asking for documentation rather than fixes, which i suspect is the wrong instinct for at least two of them. work through each one and tell me whether the answer is docs, better defaults, a validating webhook, or actual engineering, with the reasoning laid out", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "a customer's security team asked why the operator needs cluster-admin and the honest answer is that nobody trimmed the ClusterRole after the prototype. work out the minimum permissions the operator actually uses from the code, then write the page explaining each permission and why it's needed, in the tone of someone who expects to be challenged on every line", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "we tell customers that messages within a thread are delivered in server-accept order, and i now think that's a claim about the accept path that the fanout path doesn't honour. rather than change the code first, i want the actual guarantee written down accurately — what holds, under what conditions it doesn't, and what a client should do if it cares", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "messages arrive out of order for maybe one user in a thousand, here's a trace from one of them:\n\nsend msg=01HR9K2M seq=4118 client_ts=11:02:14.221 server_ts=11:02:14.402 shard=7\nsend msg=01HR9K2N seq=4119 client_ts=11:02:14.318 server_ts=11:02:14.396 shard=7\nfanout msg=01HR9K2N to=4 devices at=11:02:14.441\nfanout msg=01HR9K2M to=4 devices at=11:02:14.512\nack msg=01HR9K2N device=ios-88a1 at=11:02:14.602\nack msg=01HR9K2M device=ios-88a1 at=11:02:14.688\nrender order on device: 01HR9K2N then 01HR9K2M\n\nthe client sorts by server_ts, and as you can see the later message got the earlier server timestamp", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "le CI est rouge une fois sur cinq, toujours sur le même test d'intégration :\n\n--- FAIL: TestOperatorScalesDownIdleClusters (30.12s)\n operator_test.go:141: expected 1 replica after idle timeout, got 3\n operator_test.go:148: last reconcile at 2026-07-29T11:04:02Z, idle since 2026-07-29T11:02:31Z\n operator_test.go:152: envtest apiserver logs:\n W0729 11:04:01.882 1 dispatcher.go:210] slow webhook response: 4.1s\n W0729 11:04:02.114 1 admission.go:88] mutating webhook \"defaults.lumen.io\" timed out\nFAIL\nFAIL github.com/lumen/operator/internal/controller 62.441s\n\nen local, avec -count=20, jamais d'échec", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "fr"}
{"prompt": "CRD we're about to publish. once this is in customers' clusters we can't take it back:\n\nspec:\n versions:\n - name: v1alpha1\n served: true\n storage: true\n schema:\n openAPIV3Schema:\n type: object\n properties:\n spec:\n type: object\n properties:\n replicas: { type: integer }\n retention: { type: string }\n storage: { type: string }\n tuning:\n type: object\n x-kubernetes-preserve-unknown-fields: true\n required: [replicas]\n subresources: {}\n\nno status subresource, no defaulting, retention is a free-form string", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "on-call handover notes for the week, turn them into something the next person can actually use:\n\n- broker pods evicting on ephemeral storage, spool file is unbounded, ticket LUM-441, workaround is a cron that truncates it (yes really)\n- push delivery to ios is degraded, apple's feedback says BadDeviceToken en masse, suspect the token migration, dana is on it\n- compaction on shard 7 stalls if you let the flush queue fill, restart the node, it recovers in about 4 minutes\n- do not scale the operator deployment above 1, leader election is broken and two of them fight\n- the staging cluster's certs expire on the 12th, renewal is manual, instructions are in dana's dms somewhere\n- alert `BrokerLagHigh` fires nightly at 02:00 during compaction and is safe to ignore for 20 minutes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "storage config knobs we expose, and no documentation anywhere. write the operator's tuning reference:\n\ntuning:\n block_cache_mb: 4096 # default 512\n write_buffer_mb: 256 # default 64\n max_write_buffers: 4 # default 2\n compaction_threads: 8 # default 2\n level0_stall_threshold: 8 # default 12\n bloom_bits_per_key: 10 # default 10\n compression: zstd # none | lz4 | zstd\n wal_sync: batch # always | batch | never\n\nthings the team knows: block_cache_mb above 60% of container memory gets you OOMKilled; wal_sync=never loses acknowledged writes on power loss; compaction_threads above the core count makes stalls worse, not better", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "upgrade notes needed for the retention change, here's what actually happens:\n\n- before: `retention` was a free-form string, we parsed \"7d\", \"1 week\", \"168h\" and silently defaulted to 7 days on anything we couldn't parse\n- after: only ISO-8601 durations are accepted, the CRD rejects everything else at admission\n- on upgrade, a migration job rewrites existing values it can parse and marks clusters it can't as `Degraded` with a message\n- clusters stuck in Degraded keep serving, they just refuse spec changes until retention is fixed\n- there's no automatic rollback; downgrading the operator leaves ISO values that the old parser reads as 7 days\n\nwrite the upgrade guide for self-hosted operators", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "detox config and the CI job disagree about the simulator, so e2e never runs on CI:\n\n// .detoxrc.js\ndevices: {\n simulator: { type: 'ios.simulator', device: { type: 'iPhone 16' } }\n},\nconfigurations: {\n 'ios.sim.debug': { device: 'simulator', app: 'ios.debug' }\n}\n\n# .github/workflows/e2e.yml\n- run: xcrun simctl list devices available | grep \"iPhone 15\"\n- run: yarn detox build --configuration ios.sim.release\n- run: yarn detox test --configuration ios.sim.release --cleanup\n\nerror: Failed to find a device by type = \"iPhone 16\"\nDetox can only run on: iPhone 15, iPhone 15 Pro, iPad Air (5th generation)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "three components render the same message row and they've drifted. one component, same visuals:\n\n// MessageBubble.tsx — used in the thread\n<View style={[s.bubble, mine && s.mine]}>\n <Text style={s.body}>{m.body}</Text>\n <Text style={s.ts}>{formatTimestamp(m.serverTs)}</Text>\n</View>\n\n// SearchResultRow.tsx\n<View style={s.row}>\n <Text numberOfLines={2} style={s.body}>{m.body}</Text>\n <Text style={s.ts}>{format(m.serverTs, 'HH:mm')}</Text>\n</View>\n\n// PinnedMessage.tsx\n<Pressable onPress={onJump} style={s.pinned}>\n <Text numberOfLines={1}>{m.body}</Text>\n <Text style={s.tsSmall}>{relativeTime(m.serverTs)}</Text>\n</Pressable>\n\nthree timestamp helpers too, all in different files", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "navigation params are typed three different ways and it's why the deep link bug keeps coming back:\n\n// AppNavigator.tsx\nexport type RootStackParamList = {\n ThreadList: undefined\n Thread: { threadId: string; highlight?: string }\n Profile: { userId: string }\n}\n\n// ThreadScreen.tsx\ntype Props = { route: { params: { threadId: string; highlightMessage?: string } } }\n\n// deeplink.ts\nconst parse = (url: string): { screen: string; params: Record<string, any> } => ...\n\nthe highlight param is called `highlight` in one place and `highlightMessage` in another", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "test helpers duplicated across three packages, with the usual small differences:\n\n// internal/controller/testutil.go\nfunc newCluster(name string, replicas int32) *v1alpha1.MessageCluster { ... }\n\n// internal/webhook/helpers_test.go\nfunc makeCluster(ns, name string) *v1alpha1.MessageCluster { ... } // sets defaults\n\n// test/e2e/fixtures.go\nfunc Cluster(opts ...ClusterOpt) *v1alpha1.MessageCluster { ... } // sets defaults + status\n\nabout 60 call sites between them, and the webhook one sets a field the others don't", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "spool cap default to 8GB", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "el placeholder dice «Mensage», falta una j", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "es"}
{"prompt": "mobile team wants to drop the old react native architecture and they can't until the notification module is rewritten, which nobody has scoped. before anyone starts, i'd like the migration mapped out: what depends on the old module, what the new one has to do, how we ship it without a big-bang release, and what we do about the two native modules a contractor wrote and nobody understands", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "an audit is booked for october and it will produce findings we can't predict, which is a bad way to spend a quarter. i'd rather we found the obvious things first: how would you scope a pre-audit review of the message path, the operator's RBAC, the mobile token storage and the admin tooling, given about two weeks of one engineer's time", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "consistency model is implemented and undocumented, which means every customer question about it gets a slightly different answer depending on who replies. write the public page: what a write acknowledgement means, what a read can and cannot see, what happens during an election, and be explicit about the guarantees we do not offer rather than quietly omitting them", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "tuning knobs we expose through the CRD are documented as a list of field names with no explanation, and the dangerous ones look exactly like the harmless ones. write the tuning reference: what each knob does, sensible ranges, the interactions between them, and a prominent warning on the two that can lose acknowledged writes or get the pod OOMKilled", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "operator's finalizer logic looks fine to me and yet we have three clusters stuck terminating for two days. work out whether the teardown path can genuinely fail forever, whether removing the finalizer before the update lands is possible, and what state a partially torn-down cluster leaves behind", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "admin console's cluster detail page is unusable on a phone, which is exactly where people open it during an incident, and the stat tiles overflow into a horizontal scroll that hides the conditions table entirely. make it work down to 320px without building a separate mobile view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "i want an honest read on whether our WAL's relaxed ordering is correct with four writer threads, and if it isn't, the fix — with a test that fails reliably on the current code under tsan", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "scan and iterator both know about page pinning, and neither can be tested without a real page cache", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "how does the client decide a message is undelivered — is that a timeout, an ack, or the absence of one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "go vet is failing on a captured loop var", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "operator replicas back to 1 for now", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "one device-lookup source for fanout", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "why is the leader taking 70% of reads?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "push registration retries on every failure code including permanent ones, which is how we spent a day hammering apple with dead tokens", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "what does `has_more` actually mean on the messages endpoint when a page ends exactly on the last message", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "our alerting was assembled per-service by different people and pages for things that resolve themselves nightly, what would a coherent set of alerts look like", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "the admin console needs a proper empty state for a namespace with no clusters, because right now you get a bare table header and people assume it's broken and file a ticket. design and build it: an explanation, the kubectl command that creates one, a link to the getting-started page, and the same treatment for a filtered view that matches nothing", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt": "message row component, shared across screens", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "our cluster status pill uses four colours that are nearly indistinguishable on a projector and identical in greyscale, which came up when someone screenshared during an incident. give each status a distinct shape or glyph as well as a colour, keep the pill compact enough for the table, and make sure the degraded and progressing states read differently at a glance", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "the spool file format and its replay behaviour are known to exactly two people, and one of them is on parental leave from November. write the internal reference: the on-disk layout, how segments are ordered, what happens on a checksum failure, what replay does with a partially written record, and what an operator can safely delete when a disk fills up", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "is the session object in AsyncStorage a problem on a rooted device, or am i worrying about the wrong thing", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a plain description of what happens between a client sending and every device rendering would help me a lot", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "design system tokens we're meant to be using, and the thread screen ignores half of them:\n\ncolors.surface #0E1116 (dark) / #FFFFFF (light)\ncolors.surfaceRaised #161B22 / #F6F8FA\ncolors.textPrimary #E6EDF3 / #1F2328\ncolors.textSecondary #8B949E / #59636E\ncolors.accent #2F81F7\nspacing 4 / 8 / 12 / 16 / 24 / 32\nradius sm 6, md 10, lg 16, pill 999\ntype body 16/22, caption 13/18, title 20/26\n\nthe thread screen has 11 hardcoded hex values, three magic paddings and its own font sizes. bring it onto the tokens without changing how it looks beyond what the tokens force", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "support is guessing at what our error codes mean and inventing explanations for customers. build the reference table from the code, and where a code is genuinely unhelpful — three of them just say \"internal\" — change the message to something a human could act on", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "thread list shows a stale last-message preview for about ten seconds after sending, then corrects itself", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "message reactions need a server-side aggregate rather than counting rows on every read, and the mobile team wants it this sprint", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we need a way to mark a device's push token dead after a permanent failure code, and stop sending to it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "metro bundler is fine but the app white-screens on android release builds only:\n\nFATAL EXCEPTION: mqt_native_modules\nProcess: chat.lumen.app, PID: 9912\ncom.facebook.react.common.JavascriptException: TypeError: Cannot read property 'prototype' of undefined\n\nThis error is located at:\n in ThreadListScreen (created by SceneView)\n in SceneView (created by NativeStackView)\n in RNSScreenContentWrapper\n in NativeStackNavigator\n in AppNavigator (created by App)\n\n at com.facebook.react.modules.core.ExceptionsManagerModule.reportException(ExceptionsManagerModule.java:65)\n at java.lang.reflect.Method.invoke(Native Method)\n at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)\n\ndebug builds are perfectly fine, and it started after we enabled hermes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "query planner picks a different plan in prod than in staging for the identical query and stats:\n\n staging:\n Index Scan using idx_messages_thread_created on messages (cost=0.56..812.44 rows=412 width=88)\n Index Cond: ((thread_id = $1) AND (created_at > $2))\n Filter: (deleted_at IS NULL)\n\n prod:\n Bitmap Heap Scan on messages (cost=4412.10..214882.31 rows=88214 width=88)\n Recheck Cond: (thread_id = $1)\n Filter: ((created_at > $2) AND (deleted_at IS NULL))\n Rows Removed by Filter: 1204118\n -> Bitmap Index Scan on idx_messages_thread (cost=0.00..4390.05 rows=88214 width=0)\n\nsame postgres version, same indexes, ANALYZE run this morning on both", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "sanitizer output from the storage engine tests, only under -j16:\n\n==41221==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb8 at pc 0x0000004c1a2f\nREAD of size 8 at 0x60700000dfb8 thread T7\n #0 0x4c1a2f in lumen::store::PageCache::pin(uint64_t) src/store/page_cache.cc:141\n #1 0x4c88c0 in lumen::store::Iterator::next() src/store/iterator.cc:88\n #2 0x4d1102 in lumen::exec::ScanNode::Next() src/exec/scan.cc:52\n\n0x60700000dfb8 is located 8 bytes inside of 72-byte region\nfreed by thread T3 here:\n #0 0x49a112 in operator delete(void*)\n #1 0x4c0f40 in lumen::store::PageCache::evict(uint64_t) src/store/page_cache.cc:212\n\npreviously allocated by thread T3 here:\n #1 0x4c0221 in lumen::store::PageCache::load(uint64_t) src/store/page_cache.cc:88\n\nsingle-threaded runs are clean, and this has probably been there for months", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "pods get evicted every few hours and the events are not telling me much:\n\nEvents:\n Type Reason Age From Message\n ---- ------ ---- ---- -------\n Warning Evicted 32m kubelet The node was low on resource: ephemeral-storage. Container broker was using 41Gi, which exceeds its request of 2Gi.\n Normal Killing 32m kubelet Stopping container broker\n Warning Evicted 18m kubelet The node was low on resource: ephemeral-storage. Container broker was using 39Gi, which exceeds its request of 2Gi.\n Normal Pulled 17m kubelet Container image \"ghcr.io/lumen/broker:2.11.4\" already present on machine\n Warning BackOff 4m (x12 over 16m) kubelet Back-off restarting failed container\n\nthe broker writes a spool file to /tmp and we thought that was bounded", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "react native app drops frames scrolling long threads, here's the profiler summary:\n\nJS thread: 41 fps avg, 12 fps min\nUI thread: 58 fps avg\n\nTop offenders (self time, 10s sample):\n MessageBubble render 2841ms (3,912 renders)\n useThreadMessages selector 1102ms (3,912 calls)\n formatTimestamp 884ms (11,736 calls)\n Animated.timing 412ms\n FlatList onViewableItemsChanged 388ms\n\nRe-render reasons for MessageBubble:\n props.message changed 12%\n props.onLongPress changed 71%\n context value changed 17%\n\nthe list has 400 items and windowSize is at the default", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "nightly compaction stalled and the only clue is this:\n\n[compaction] level=1 files=41 target=L2 started\n[compaction] level=1 read 2.1GB in 41s\n[compaction] level=2 merge started, output sst=00041.sst\n[compaction] level=2 merge progress 12% after 300s\n[compaction] level=2 merge progress 12% after 600s\n[compaction] level=2 merge progress 12% after 900s\n[bg] flush queue depth 8 (max 8), writes stalled\n[bg] write stall total 14m22s\n[compaction] level=2 merge progress 13% after 1200s\n\nthe machine is not CPU bound, iostat shows 4% utilisation, and there is 400GB free", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "someone's proposed this for the operator's finalizer handling. sound?\n\nfunc (r *ClusterReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {\n\tvar c v1alpha1.MessageCluster\n\tif err := r.Get(ctx, req.NamespacedName, &c); err != nil {\n\t\treturn ctrl.Result{}, client.IgnoreNotFound(err)\n\t}\n\tif !c.DeletionTimestamp.IsZero() {\n\t\tif err := r.teardown(ctx, &c); err != nil {\n\t\t\treturn ctrl.Result{RequeueAfter: 10 * time.Second}, nil\n\t\t}\n\t\tcontrollerutil.RemoveFinalizer(&c, finalizerName)\n\t\treturn ctrl.Result{}, r.Update(ctx, &c)\n\t}\n\tcontrollerutil.AddFinalizer(&c, finalizerName)\n\tif err := r.Update(ctx, &c); err != nil {\n\t\treturn ctrl.Result{}, err\n\t}\n\treturn r.reconcileNormal(ctx, &c)\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "por favor, revisa este helm chart antes de que lo subamos al repo público:\n\napiVersion: apps/v1\nkind: StatefulSet\nspec:\n replicas: {{ .Values.replicas }}\n template:\n spec:\n securityContext:\n runAsUser: 0\n containers:\n - name: broker\n image: \"ghcr.io/lumen/broker:{{ .Values.tag | default \"latest\" }}\"\n env:\n - name: ADMIN_TOKEN\n value: {{ .Values.adminToken | quote }}\n ports:\n - containerPort: 9092\n hostPort: 9092\n volumeMounts:\n - name: spool\n mountPath: /tmp/spool\n volumes:\n - name: spool\n emptyDir: {}\n\nlo van a instalar clientes en sus propios clústeres", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "es"}
{"prompt": "hook that every screen uses. i keep being told it's fine and the app disagrees:\n\nexport function useThreadMessages(threadId: string) {\n const [messages, setMessages] = useState<Message[]>([])\n const { socket } = useSocket()\n\n useEffect(() => {\n let cancelled = false\n api.messages(threadId).then(m => { if (!cancelled) setMessages(m) })\n const off = socket.on('message', (m: Message) => {\n if (m.threadId === threadId) setMessages(prev => [...prev, m].sort(byServerTs))\n })\n return () => { cancelled = true; off() }\n }, [threadId, socket])\n\n const onLongPress = (id: string) => actions.openMenu(id)\n return { messages, onLongPress }\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "buffer pool eviction policy, inherited and never questioned:\n\nPage* PageCache::Evict() {\n std::lock_guard<std::mutex> g(mu_);\n auto victim = lru_.back();\n while (victim && victim->pin_count.load() > 0) {\n victim = victim->prev;\n }\n if (!victim) {\n victim = lru_.back(); // give up, take the last one anyway\n }\n lru_.erase(victim);\n map_.erase(victim->page_id);\n return victim;\n}\n\nis the fallback there for a reason anyone can defend, and what does it do to a pinned page under load?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "security asked about our token handling in the mobile app and this is what i found:\n\n// auth/storage.ts\nimport AsyncStorage from '@react-native-async-storage/async-storage'\n\nexport const saveSession = (s: Session) =>\n AsyncStorage.setItem('session', JSON.stringify(s))\n\nexport const loadSession = async (): Promise<Session | null> => {\n const raw = await AsyncStorage.getItem('session')\n return raw ? JSON.parse(raw) : null\n}\n\n// api/client.ts\nconst client = axios.create({ baseURL: API })\nclient.interceptors.request.use(async cfg => {\n const s = await loadSession()\n if (s) cfg.headers.Authorization = `Bearer ${s.accessToken}`\n return cfg\n})\n\nrefresh tokens live in the same object, ttl 90 days", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "raw notes from the incident call, we owe the customer a written explanation by tomorrow:\n\n- 09:12 customer reports messages not arriving on ios\n- 09:20 we confirm push failures at 98%, android unaffected\n- 09:31 rotated the apns key on monday, suspicion falls there\n- 09:52 rules out the key, the error is BadDeviceToken not auth\n- 10:14 discover the token migration job re-encoded tokens as base64 twice\n- 10:31 stopped the job, 41k tokens affected out of 220k\n- 11:02 re-registration push sent via a silent notification, most devices recover\n- 12:40 remaining 6k devices need to open the app to re-register\n- no messages were lost, they were queued and delivered on re-registration", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "my commit is ready and i always write terrible messages. the diff:\n\ndiff --git a/src/exec/scan.cc b/src/exec/scan.cc\n@@ -41,12 +41,19 @@ Status ScanNode::Next(Batch* out) {\n- while (out->size() < batch_size_) {\n- auto page = cache_->Pin(iter_->page_id());\n- out->Append(iter_->Value());\n- cache_->Unpin(page);\n- iter_->Next();\n- }\n+ auto page = cache_->Pin(iter_->page_id());\n+ auto guard = absl::MakeCleanup([&] { cache_->Unpin(page); });\n+ while (out->size() < batch_size_) {\n+ if (iter_->page_id() != page->id) {\n+ cache_->Unpin(page);\n+ page = cache_->Pin(iter_->page_id());\n+ }\n+ out->Append(iter_->Value());\n+ iter_->Next();\n+ }\n return Status::OK();\n }\n\nwe use conventional commits and the body should explain why, not what", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "schreib bitte die Release Notes für 2.12 aus diesen Tickets:\n\nLUM-402 Broker: Spool-Datei wird jetzt bei 2 GB rotiert statt unbegrenzt zu wachsen\nLUM-417 Operator: Leader Election repariert, mehrere Replicas sind jetzt unterstützt\nLUM-421 Storage: Kompaktierung blockiert nicht mehr, wenn die Flush-Queue voll ist\nLUM-433 API: `retention` akzeptiert jetzt nur noch ISO-8601-Dauern, alte Werte werden beim Upgrade migriert\nLUM-441 Mobile: Push-Registrierung wird bei ungültigem Token automatisch erneuert\nLUM-448 Breaking: `tuning.wal_sync=never` wurde entfernt\n\nZielgruppe sind Betreiber, die selbst hosten", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "de"}
{"prompt": "gostava de ter um documento sobre o modelo de consistência, a partir do que está no código:\n\n- as escritas vão para o líder do shard e são replicadas para dois seguidores\n- o ack ao cliente acontece depois de um seguidor confirmar, não os dois\n- as leituras podem ir para qualquer réplica, exceto quando o cliente envia o cabeçalho `X-Read-Your-Writes`\n- nesse caso a leitura vai para o líder e espera pelo LSN indicado pelo cliente\n- durante uma eleição, as escritas falham com 503 durante 2 a 5 segundos\n- não há garantia de leitura monotónica entre réplicas diferentes\n\nescreve isto como página de documentação pública, com os avisos que forem precisos", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "pt"}
{"prompt": "eslint and the react compiler disagree about our hooks, and i just want a green build:\n\nsrc/hooks/useThreadMessages.ts\n 14:6 warning React Hook useEffect has a missing dependency: 'api' react-hooks/exhaustive-deps\n 22:9 error Ref values ('cancelled.current') should not be read during render react-hooks/react-compiler\n\nsrc/screens/ThreadListScreen.tsx\n 41:11 error Component definition is missing display name react/display-name\n 88:3 warning Fast refresh only works when a file only exports components react-refresh/only-export-components\n\nsrc/components/MessageBubble.tsx\n 102:5 error 'onLongPress' changes on every render, wrap it in useCallback react-hooks/react-compiler\n\n✖ 5 problems (3 errors, 2 warnings)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "clang-tidy on the storage engine, the new checks are noisy but two look real:\n\nsrc/store/page_cache.cc:141:10: warning: 'pin' is called on a possibly-null pointer [bugprone-unchecked-optional-access]\nsrc/store/page_cache.cc:212:5: warning: loop variable 'victim' is copied but only used as const reference [performance-for-range-copy]\nsrc/exec/scan.cc:88:22: warning: narrowing conversion from 'size_t' to 'int' [bugprone-narrowing-conversions]\nsrc/wal/writer.cc:44:9: warning: atomic operation on 'latest_lsn_' uses relaxed ordering, consider seq_cst [concurrency-mt-unsafe]\nsrc/util/arena.cc:19:1: warning: function 'Allocate' exceeds recommended size/complexity thresholds [readability-function-size]\n\n5 warnings generated, CI treats them as errors since last week", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "kustomize diff between our two environments, one of these is why prod restarts more:\n\n--- base/broker/statefulset.yaml\n+++ overlays/prod/statefulset.yaml\n@@\n resources:\n requests:\n- memory: 2Gi\n- ephemeral-storage: 2Gi\n+ memory: 8Gi\n+ ephemeral-storage: 2Gi\n limits:\n- memory: 4Gi\n+ memory: 8Gi\n@@\n env:\n- - name: BLOCK_CACHE_MB\n- value: \"512\"\n+ - name: BLOCK_CACHE_MB\n+ value: \"6144\"\n@@\n terminationGracePeriodSeconds: 30\n+ # prod only\n+ livenessProbe:\n+ initialDelaySeconds: 5\n+ periodSeconds: 5\n+ failureThreshold: 2", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "prometheus rule that pages us every night at 02:00 and is always benign:\n\n- alert: BrokerLagHigh\n expr: max by (shard) (broker_consumer_lag) > 10000\n for: 2m\n labels:\n severity: page\n annotations:\n summary: \"broker lag on shard {{ $labels.shard }}\"\n\nnightly pattern:\n 02:00 lag climbs to ~40k during compaction\n 02:18 lag drains to under 1k\n 02:19 alert resolves\n\nduring a real incident in june, lag went to 400k and stayed there for an hour", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependabot on the mobile app, four PRs open and i want to merge what's safe:\n\nreact-native 0.79.2 -> 0.80.0 (major-ish, they don't do semver properly)\n@react-navigation/native 6.1.18 -> 7.0.2 (breaking: linking config shape changed)\naxios 1.7.4 -> 1.11.2 (advisory GHSA-jr83, SSRF via redirect)\ndate-fns 3.6.0 -> 4.1.0 (breaking: timezone handling moved to a separate package)\n\nour app pins react-native in three places: package.json, ios/Podfile.lock and the expo config plugin", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "this reconciler does everything and i want the same behaviour in pieces i can test:\n\nfunc (r *ClusterReconciler) reconcileNormal(ctx context.Context, c *v1alpha1.MessageCluster) (ctrl.Result, error) {\n\t// 40 lines: ensure statefulset, diff spec, update if drifted\n\t// 30 lines: ensure service, headless service, and the ingress if enabled\n\t// 25 lines: ensure configmap from spec.tuning with defaults applied inline\n\t// 35 lines: ensure PVCs, resize if storage grew, refuse if it shrank\n\t// 50 lines: compute status from pod conditions and write it back\n\t// 20 lines: emit events for every transition\n\treturn ctrl.Result{RequeueAfter: time.Minute}, nil\n}\n\n200 lines in one function, one test that spins up envtest and asserts on the end state", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "error handling in the storage layer, three styles in one file:\n\nStatus PageCache::Load(uint64_t id, Page** out) {\n if (!map_.contains(id)) return Status::NotFound(\"page\");\n ...\n}\n\nPage* PageCache::Pin(uint64_t id) {\n auto it = map_.find(id);\n if (it == map_.end()) { LOG(FATAL) << \"pin of unknown page \" << id; }\n ...\n}\n\nabsl::StatusOr<Page*> PageCache::Fetch(uint64_t id) {\n ...\n}\n\nsame class, three conventions, and one of them crashes the process on a bad id", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "quatre endroits construisent la même requête de fanout, avec des différences subtiles :\n\n// fanout.go\ndevices, _ := f.devices.For(ctx, m.ThreadID)\n\n// presence.go\nrows, _ := db.Query(ctx, `SELECT device_id FROM devices WHERE thread_id = $1 AND active`, tid)\n\n// admin/tools/resend.go\nrows, _ := db.Query(ctx, `SELECT device_id FROM devices WHERE thread_id = $1`, tid)\n\n// push/retry.go\ndevices := cache.Devices(tid) // peut être périmé de 5 minutes\n\nune seule source, s'il te plaît, et sans changer le comportement du chemin critique", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "fr"}
{"prompt": "config plumbing in the operator, currently five layers deep:\n\ndefaults := DefaultTuning()\nif c.Spec.Tuning != nil {\n merged := mergeMaps(defaults.AsMap(), c.Spec.Tuning.AsMap())\n if env := os.Getenv(\"LUMEN_TUNING_OVERRIDE\"); env != \"\" {\n var override map[string]any\n _ = json.Unmarshal([]byte(env), &override)\n merged = mergeMaps(merged, override)\n }\n if cm, err := r.getLegacyConfigMap(ctx, c); err == nil {\n merged = mergeMaps(cm.Data, merged) // note: legacy loses\n }\n tuning = TuningFromMap(merged)\n} else {\n tuning = defaults\n}\n\nsame resolved values, one obvious precedence order", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "fr"}
{"prompt": "quarter planning, and this is what landed in my inbox. i need a sequenced plan out of it:\n\n- self-hosted customers want a supported upgrade path between minor versions; today they redeploy and hope\n- two customers have asked for multi-region, one of them contractually\n- the mobile team wants to drop the old architecture and cannot until the notification module is rewritten\n- storage wants six weeks to finish the compaction work, otherwise the stalls continue\n- support burden is dominated by three things: retention config, push registration, and pod evictions\n- we have one platform engineer and they're on parental leave from November\n- there's a security audit booked for October that will produce work we can't predict", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "customer requirement we've signed up to, and nobody has thought about how:\n\n\"Message data for EU tenants must remain within the EU, including backups, logs and any derived data such as search indexes. Cross-region replication is permitted only between EU regions. Support staff outside the EU must not be able to read message content, though they may see metadata necessary for support. The customer requires evidence of this control, not an assurance.\"\n\nwe currently have one region, logs go to a US SaaS, and support has a debug tool that dumps message bodies. i want the plan and an honest list of what we'd have to give up", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the cluster detail page in our admin console, build it in react:\n\nCluster detail\n- Header: cluster name, namespace as a muted subtitle, a status pill (Ready / Progressing / Degraded / Unknown) and a kebab menu with Edit, Restart and Delete.\n- Summary strip: four stat tiles — replicas ready, storage used vs requested, message rate, consumer lag — each with a 24h sparkline and a click-through to metrics.\n- Conditions table: type, status, reason, message, last transition, newest first, with long messages truncated and expandable.\n- Events panel: last 50 events, warning ones flagged, auto-refreshing every 10 seconds without jumping the scroll position.\n- Degraded state: a banner above the summary explaining the condition in plain language with a link to the matching docs page.\n- Everything must be readable at 320px wide because people open this on phones during incidents.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings from a customer's audit of our mobile app, prioritise and implement:\n\n1. Message bubbles are announced as \"button, text\" with no sender or timestamp; VoiceOver users cannot tell who wrote what.\n2. The send button has no accessibility label, only an icon.\n3. Contrast on the timestamp text is 2.8:1 against the bubble background.\n4. The typing indicator is announced repeatedly, interrupting reading.\n5. Long-press is the only way to react to a message; there is no accessible alternative.\n6. Dynamic Type above the default clips the reply bar and hides the send button entirely.\n7. Focus order in the thread jumps from the header to the reply bar, skipping the message list.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "api spec we agreed with the mobile team, needs building on the server:\n\nGET /v2/threads/{id}/messages\n query: before (message id), after (message id), limit (default 50, max 200)\n exactly one of before/after may be given; neither means newest page\n response: { data: Message[], has_more: boolean, oldest_id, newest_id }\n Message: { id, thread_id, author_id, body, server_ts, edited_at?, deleted: bool, reactions: {emoji: count} }\n deleted messages come back with body omitted and deleted: true, they still occupy a position\n reads must be consistent within a page — no message may appear twice across pages if nothing changed\n a client with X-Read-Your-Writes: <lsn> must not see a page missing its own just-sent message", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "axios advisory bump on the mobile app", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "unread badge counts deleted messages", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "detox targets iPhone 15 on CI", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "BrokerLagHigh needs a 20 minute for-clause", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "drop hostPort from the broker chart", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "context cancel is discarded in the reconciler", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "block cache 6GB in an 8GB limit", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "le champ `retention` accepte encore n'importe quoi", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "fr"}
{"prompt": "typing indicator should fade, not pop", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "our getting-started guide assumes a cluster with cluster-admin, a default storage class and no admission policies, which describes approximately none of our self-hosted customers. rewrite it for someone installing into a restricted namespace, including the values they'll need to override, and be explicit about what will fail and how the failure looks", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "the iterator rewrite makes sequential scans twice as fast and point-lookup misses nearly three times slower, with allocations up by an order of magnitude on mixed workloads. our production traffic is mostly point lookups. read the code alongside the benchmark and tell me whether the regression is inherent to the design or an artefact of how the batch buffer is sized", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "send button needs a label for VoiceOver", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "pinned message strip above the list", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "status pill colours are too similar", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "sparklines on the cluster stat tiles", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "die Zeitstempel sind zu blass", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "de"}
{"prompt": "reply bar jumps when the keyboard opens", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "events panel scroll jumps on refresh", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "conditions table needs a newest-first sort", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "`highlightMessage` everywhere, pick one name", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "split reconcileNormal into steps", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "les helpers de test dans un seul paquet", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "fr"}
{"prompt": "`PageCache::Fetch` naming, be consistent", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "pull the tuning merge into one function", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "inline `makeCluster`, one caller left", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "comment the memory ordering in wal/writer", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "upgrade notes for the retention change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "resumo do incidente de push, em português", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "pt"}
{"prompt": "document the minimum RBAC we need", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "PR description for the spool rotation", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "who pins pages during a scan?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "¿el fanout garantiza el orden por hilo?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "es"}
{"prompt": "walk me through leader election here", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "threads reorder themselves on reconnect", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "release build white-screens, debug is fine", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "reconcile loop spins at 60/s", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "warum verlieren wir jede Nacht Push-Tokens?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "de"}
{"prompt": "presence endpoint for a thread", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "design the EU-only story, then start on logs", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "shape the upgrade path, then write the migration", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "back on the push thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "finish what dana started", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "smoother", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "operator, again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "do the thing from the handover notes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "algo rápido antes de la demo", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "es"}
{"prompt": "next chunk of the storage work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "whatever unblocks QA", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidy before review", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "same treatment as the thread screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "もう一度、あの通知の件", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "ja"}
{"prompt": "keep going on the console", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "plan for next quarter", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "anything you think matters", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "multi-region is now contractual for one customer and vaguely promised to another, and we've never run more than one region. i need to understand what it means for us before anyone commits to a date: whether we replicate at the storage layer or the application layer, what happens to message ordering across regions, how a client picks a region, and what our failover story would actually be when the network partitions rather than when a region cleanly disappears", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "self-hosted customers currently upgrade by redeploying the chart and hoping, which has gone badly twice this quarter, both times because a CRD field changed shape. i want a real upgrade story designed: version skew we support, how CRD migrations run, what the operator does when it finds resources it doesn't understand, whether we can roll back at all, and how a customer knows it worked", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "read-your-writes currently pins reads to the leader, which is why the leader carries most of our read traffic on the busiest threads. the proposal is per-client LSN tracking with follower reads that wait, and i can see three ways it goes wrong with mobile clients that reconnect constantly. talk me through the design space and what you'd actually recommend for our size", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "on-call handover happens verbally on a friday afternoon and the notes are a slack message that scrolls away. from this week's incidents and the current known issues, write the handover document template plus this week's filled-in version, in a form where the person picking it up can tell what is on fire, what is smouldering, and what they can ignore", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "nobody can explain why the buffer pool sometimes evicts a pinned page, and the code has a fallback branch with no comment that appears to do exactly that. i don't want it changed yet — read it, work out what happens to a scan holding that page, and tell me whether the crash we saw last month is explained by it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "ordering trace from a customer shows a later message getting an earlier server timestamp, which either means our clocks are wrong or our accept path is doing something i don't understand. before we call it a bug, go through how server_ts is assigned, how the shard channel orders, and whether two messages on the same shard can be timestamped out of order", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "three components render a message row with their own timestamp helper, their own truncation rules and their own styles, which is why search results look subtly different from the thread. consolidate them into one component with props for the variations, keeping each screen looking exactly as it does today, and delete the two helpers that fall out", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "storage layer uses three error conventions in the same class — a Status return, a StatusOr, and a LOG(FATAL) that takes the process down on a bad page id — and callers handle whichever they happen to hit. pick the convention the newest code uses, apply it throughout, and make sure no path can still abort the process on bad input", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "tuning resolution in the operator goes through defaults, the spec, an environment override and a legacy configmap, merged in an order that surprises everyone including the person who wrote it. make the precedence explicit and testable, keep the resolved values identical for every cluster we have in the field, and leave the legacy path working until we can remove it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "messages occasionally arrive out of order on ios but not android, roughly one user in a thousand, and both clients sort by the same field. i've stared at the fanout code and the push path and can't see it. before assuming it's the client, i'd like the whole path from accept to render examined properly", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "e2e tests fail about one run in five on CI and never locally, always on the test that waits for an idle cluster to scale down. the envtest logs mention a slow admission webhook right before the failure, which may or may not be related", "purpose": "debugging", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "CI installs the whole toolchain from scratch on every job because someone disabled caching to debug something in march and never turned it back on, and the mobile job now takes 22 minutes. turn caching back on for yarn, pods and gradle, verify the builds are still reproducible, and note what you changed", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "data residency for EU tenants is contractual and we currently have one region, logs in a US SaaS and a support tool that dumps message bodies. i want the design for what compliant looks like, and then the first piece implemented: keeping message content out of the logs entirely", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "before the mobile rewrite starts i'd like the notification module's responsibilities mapped out properly — registration, token refresh, delivery receipts, deep links — and then the registration piece built against the new architecture so we can prove the approach works", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "spool needs rotation and we also need to decide what \"drop the oldest\" means for delivery guarantees, because right now we'd be silently losing messages. think through the semantics first, write them down, then implement rotation with whatever loud signals you decide on", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "unsere Retention-Konfiguration ist ein Freitextfeld und die Migration auf ISO-8601 steht an. Ich hätte gern zuerst einen Plan, wie wir bestehende Cluster migrieren, ohne dass jemand in Degraded landet, und danach den Validierungs-Webhook dafür", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "de"}
{"prompt": "consistency model needs writing up for customers and i suspect the act of writing it will surface at least one place where the code doesn't match the claim. do both: the public page, and a list of every claim you couldn't verify from the code", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "escreve o guia de instalação para clientes que alojam o produto, e valida no chart se o que dizemos sobre permissões é verdade — desconfio que pedimos muito mais do que precisamos", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "pt"}
{"prompt": "test helpers are duplicated across three packages with subtly different defaults, which is why a test can pass in one package and fail in another with the same input. unify them, then document the fixture conventions so the next person doesn't add a fourth", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "navigation params are typed in three places with two different names for the same field, and the deep link bug keeps coming back because of it. fix the types properly, then add the short note to the contributing guide about where params are declared", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "go packages are organised by layer — models, services, handlers — and every feature touches all three, so nothing is local", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "rename `MessageCluster` to `Cluster` in the CRD group, it reads terribly in kubectl output", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "mobile app has both a `utils` and a `helpers` folder, imported interchangeably, thirty files between them", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "could someone explain what happens to in-flight messages when a shard leader changes, i can't tell from the code", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "i'd like a read on the new iterator benchmarks before we merge, particularly the point-lookup miss regression", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "why does the reply bar re-render when a peer starts typing in a different thread", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "is it normal for the operator to log a status update on every reconcile even when nothing changed", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "someone should sanity check our CRD before it ships, particularly the free-form tuning field and the missing status subresource", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "docs/consistency.md describes two followers acknowledging before we ack the client, which is not what the code does", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "a short note for the team about why we're capping the spool, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "CRD field descriptions are empty, which means `kubectl explain` tells operators nothing at all", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "write the docs page answering \"why is my cluster Degraded\", covering all six conditions we can set", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "liveness probe on the prod overlay has a 5 second delay and 2 failures, which restarts pods mid-compaction", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "operator's default retention is 7 days in code and 30 days in the docs, and one of them has to change", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "push retries use a fixed 30 second delay with no jitter, so every failure lands in the same second", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "la búsqueda de mensajes ignora los acentos, y en español eso rompe la mitad de las consultas", "purpose": "quickFix", "secondary": "backendImpl", "mixed": true, "difficulty": 0.4, "slice": "mixed", "lang": "es"}
{"prompt": "one shard's consumer lag climbs steadily every night and drains by morning, and nobody knows whether that's compaction or a slow consumer", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "what should our story be for customers who want to run us on ARM nodes? two have asked and we've never built for it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether search belongs in the storage engine or as a separate index before anyone starts building it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "how should we handle schema evolution for the message format now that self-hosted customers can be six months behind us", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns a device's pending messages since a given LSN, for the reconnect path", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "admin debug tool should redact message bodies unless the operator holds a break-glass role", "purpose": "backendImpl", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "per-thread rate limiting on the send path, since one automated client can currently saturate a shard", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "cluster list page needs filtering by status and namespace, and it should remember what you picked", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "whatever's least embarrassing before friday", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick up where the doc left off", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "thread list is a FlatList that re-renders every row whenever any thread updates, which on a busy account means the whole list rebuilds several times a second and scrolling turns to mush. keep the rows visually identical but make each one independent, memoise the row callbacks properly, and fix the last-message preview so it updates without dragging the rest of the list with it", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "message reactions currently open a long-press menu that appears under the thumb and covers the message being reacted to, and there's no way to reach them at all with a keyboard or a switch control. rework the interaction: an accessible affordance on each row, the picker positioned so it never covers its own message, and a sensible focus return when it closes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "support answers \"why is my push not arriving\" from scratch every time, usually badly, because the answer depends on the token state, the apns feedback, whether the device has opened the app recently, and our own retry state. write the troubleshooting page that walks through those in order, with what to check and what each outcome means", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "the mobile app stores its session, including a ninety-day refresh token, as plain JSON in AsyncStorage, and an interceptor reads it on every request. before i take this to the security review, i want an assessment of what that actually exposes on a compromised device, what the platform keychain would change, and whether the ninety days is the bigger problem", "purpose": "review", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "our go packages are split by layer, so a single feature touches models, services and handlers and nothing is ever local to one directory. restructure by feature instead, keeping the public API and every behaviour identical, and do it in a sequence where the build stays green after each step rather than one enormous move commit", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "scan and iterator both know about page pinning, which means neither can be unit tested without a real page cache and a real file, and our tests are correspondingly slow and flaky. introduce a seam so the iterator can be tested against a fake, without changing the hot path's performance characteristics or its current behaviour", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "search across message bodies is being asked for by three customers and we have no plan for it. i'd like the options weighed — in the storage engine, a separate index, or a managed service — against our EU data residency commitment, our self-hosted customers who won't run another component, and the fact that we have nobody with search experience", "purpose": "planning", "secondary": "review", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "customers running us on ARM nodes have asked twice now and we've never built for it, which means images, the storage engine's intrinsics, and whatever assumptions our chart makes about node labels. work out what supporting ARM would actually involve and whether it's a week or a quarter, then start on the multi-arch image build if it's the former", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "we need an endpoint the mobile clients hit on reconnect that returns everything they missed since a given LSN, bounded so a device offline for a month doesn't pull a gigabyte. cap it, tell the client when it's been truncated so it can fall back to a fresh sync, and make sure it works when the LSN is from a shard that has since been split", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt":"Kestrel: projects/dovetail/apps/console/routes/usage.svelte 里的 DovetailLumenChartStore 最近在 Playwright 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 Playwright\n- 保持兼容性和取消语义\n- 改动只限于 DovetailLumenChartStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Does DovetailSableParserService 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":"Is there a cleaner way to separate DovetailSummitProxyStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'DovetailEmberRelayFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[DovetailEmberRelayFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/dovetail/ml/pipeline/features.py:144: error: -[DovetailEmberRelayFlowTests 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 '-[DovetailEmberRelayFlowTests 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\nFinish the visible DovetailEmberRelayFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Lumen: # projects/dovetail/src/sync/reconcile.ts\n[worker.dovetailnimbusformflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailnimbusformflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailnimbusformflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailNimbusFormFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44138\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/dovetail/src/sync/reconcile.ts and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"The behavior of DovetailWrenExportService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/dovetail/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- make rollback possible without deleting user data\n- retain the current Playwright operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"DovetailFlintTimelineCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Maple: The DovetailVelaDrawerFlow surface in projects/dovetail/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.3,"slice":"core","lang":"en"}
{"prompt":"Security flagged DovetailMarbleTokenService for a read-only pass because its Terraform 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- make rollback possible without deleting user data\n- retain the current Terraform operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS 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":"UI ticket DES-44128: finish the compact DovetailCraneWorkspaceFlow filter experience\n\nRoute: /catalog/search\nSource: projects/dovetail/db/migrations/20260730_events.sql\nFramework: Playwright\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\nBring DovetailCraneWorkspaceFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"How does DovetailAmberFilterFlow propagate cancellation through the Terraform boundary, and are there code paths where ownership becomes ambiguous? Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Em projects/dovetail/web/components/FilterDrawer.vue, o DovetailDeltaCanvasStore tem um problema intermitente no fluxo de Redis Streams. 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 Redis Streams\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao DovetailDeltaCanvasStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"pt"}
{"prompt":"For DovetailPrismCacheCoordinator, assess ownership and failure handling in projects/dovetail/app/src/main/SyncWorker.kt; once that is complete, capture the contract and rollback note for consumers. Work from projects/dovetail/app/src/main/SyncWorker.kt, stay with Playwright, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-44148\n\n08:02 deploy DovetailWillowCodecFlow 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 DovetailWillowCodecFlow 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":"DovetailJuniperCLICoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"What is the safest way to split projects/dovetail/cmd/exporter/main.py into independently owned modules while DovetailMoonlitSDKService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Rename DovetailTideWorkerStore's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-44133: retire the legacy replay path for DovetailPrismCacheFlow\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 DovetailPrismCacheFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/dovetail/web/components/FilterDrawer.vue: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: dovetailcopperbridgeflow::scheduler::LeaseTask::flush\n at ./projects/dovetail/web/components/FilterDrawer.vue:217:18\n 4: dovetailcopperbridgeflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nFind the source of this DovetailCopperBridgeFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Does DovetailBasilRunnerService 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":"DovetailCedarPolicyCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Nimbus: Ticket OPS-44111: retire the legacy replay path for DovetailBeaconStoreFlow\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 DovetailBeaconStoreFlow 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":"Opal: What does DovetailOspreyJobService own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Is DovetailTideWorkerService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale DovetailSlateEditorStore value; the cause, desired value, and affected assertion are already agreed. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Core Data operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Prism: Incident timeline — INC-44116\n\n08:02 deploy DovetailFrostPanelFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current DovetailFrostPanelFlow 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":"Could the reasoning behind DovetailDriftConsoleStore's Redis Streams choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"DovetailFlintTimelineService 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":"Two asks around DovetailCopperBridgeCoordinator: (1) find the unknown cause of stale cursors when a page is resumed; (2) give the existing implementation a read-only safety pass. Make rollback possible without deleting user data, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"DovetailPineMetricsCoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Describe DovetailFernSnapshotStore's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Quartz: Ticket OPS-44149: retire the legacy replay path for DovetailEchoRegistryFlow\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 DovetailEchoRegistryFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"En projects/dovetail/config/staging.toml, DovetailBeaconStoreStore tiene un problema intermitente en el flujo de React 19. 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 React 19\n- conservar compatibilidad y cancelación\n- limitar el cambio a DovetailBeaconStoreStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"es"}
{"prompt":"DovetailRavenSessionService'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":"Raven: Incident timeline — INC-44118\n\n08:02 deploy DovetailFernSnapshotFlow 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 DovetailFernSnapshotFlow 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":"Fresh release brief for DovetailAcornWidgetCoordinator:\n- primary outcome: assess ownership and failure handling in projects/dovetail/engine/render/atlas.cpp\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/dovetail/engine/render/atlas.cpp\n- platform constraint: Terraform\n- known complication: an empty state that flashes before cached data arrives\n\nBoth results are required, but they should remain independently reviewable. Make rollback possible without deleting user data; 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.8,"slice":"mixed","lang":"en"}
{"prompt":"DovetailCoralUploadCoordinator is blocking the next release because a deadlock that appears only during shutdown. I need two concrete outcomes from a single pass: find the unknown cause of a deadlock that appears only during shutdown, and capture the contract and rollback note for consumers. Use the existing Core Data conventions in projects/dovetail/Sources/CLI/Commands/Doctor.swift; make rollback possible without deleting user data. 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":"debugging","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"# projects/dovetail/pkg/cache/lease.rs\n[worker.dovetailasterwebhookflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailasterwebhookflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailasterwebhookflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailAsterWebhookFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44126\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/dovetail/pkg/cache/lease.rs and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"On compact widths, DovetailCinderAuthService'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":"Sable: Incident timeline — INC-44156\n\n08:02 deploy DovetailMosaicGridCoordinator 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 DovetailMosaicGridCoordinator 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":"Tide: Ticket OPS-44143: retire the legacy replay path for DovetailLumenChartFlow\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 DovetailLumenChartFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"A previously stable test around DovetailWillowCodecStore 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":"diff --git a/projects/dovetail/ui/settings/PrivacyPane.tsx b/projects/dovetail/ui/settings/PrivacyPane.tsx\nindex 62d71aa..90f3c1e 100644\n--- a/projects/dovetail/ui/settings/PrivacyPane.tsx\n+++ b/projects/dovetail/ui/settings/PrivacyPane.tsx\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\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Read the artifact above as a skeptical reviewer. Is DovetailTideWorkerFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"DovetailMicaProfileCoordinator: polish the last piece","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Support wants the behavior in projects/dovetail/web/components/FilterDrawer.vue recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Ticket OPS-44113: retire the legacy replay path for DovetailWrenExportFlow\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Add the bounded DovetailWrenExportFlow replay flow described here, including authorization, key rotation, cancellation, lag metrics, and tests for malformed and cross-tenant cursors.","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Umbra: Ticket OPS-44136: retire the legacy replay path for DovetailGarnetModalFlow\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 DovetailGarnetModalFlow 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":"DovetailFernSnapshotCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Corrija o timeout de DovetailCloudReconcilerService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"pt"}
{"prompt":"Before we approve DovetailNimbusFormService, assess whether lost focus when the drawer animation finishes is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"DovetailKiteSchedulerFlow needs an idempotent replay endpoint backed by Core Data; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"DovetailSpruceDaemonCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"The next client release depends on a new DovetailCoralUploadService capability in projects/dovetail/Sources/App/SessionStore.swift, with Core Data already chosen by the platform group. Implement the endpoint and durable cursor, enforce tenant authorization and idempotency, emit useful spans, cap work per request, and include focused tests for retries, cancellation, and malformed cursors.\n\nConstraints:\n- make rollback possible without deleting user data\n- stay compatible with the existing Core Data deployment\n- keep the work scoped to DovetailCoralUploadService and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Vela: The data is already available in projects/dovetail/pkg/cache/lease.rs; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Parse DovetailHarborIndexStore's signed cursor","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up DovetailWrenExportCoordinator. First, find the unknown cause of out-of-order events after consumer rebalancing. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/dovetail/app/src/main/SyncWorker.kt, which follows Playwright conventions and currently suffers from out-of-order events after consumer rebalancing. Make rollback possible without deleting user data.\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":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"DovetailSpruceDaemonService returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/dovetail/web/components/FilterDrawer.vue and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Willow: Ticket OPS-44141: retire the legacy replay path for DovetailMicaProfileFlow\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 DovetailMicaProfileFlow 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":"// projects/dovetail/infra/modules/edge/main.tf\nfinal class DovetailFlintTimelineFlowCoordinator {\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 DovetailFlintTimelineFlow; 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":"DovetailWillowCodecCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"PM is preparing the DovetailIrisBatchService 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 DovetailIrisBatchService\n- make rollback possible without deleting user data\n\nThe relevant code crosses game tooling, data pipelines, macOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Split DovetailJuniperCLIStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-44154\n\n08:02 deploy DovetailMarbleTokenCoordinator 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 DovetailMarbleTokenCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"DovetailSlateEditorCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"A copied hex color in DovetailEmberRelayService lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"DovetailTideWorkerCoordinator needs a paired pass: assess ownership and failure handling in projects/dovetail/workers/thumbnail/consumer.ex, plus capture the contract and rollback note for consumers. Use projects/dovetail/workers/thumbnail/consumer.ex as the source of truth, preserve the Terraform contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Xylem: # projects/dovetail/cmd/exporter/main.py\n[worker.dovetailslateeditorflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailslateeditorflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailslateeditorflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailSlateEditorFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44117\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/dovetail/cmd/exporter/main.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Yarrow: Two asks around DovetailNovaPickerCoordinator: (1) lay out a staged migration for DovetailNovaPickerCoordinator; (2) also add the visible loading and offline states. Make rollback possible without deleting user data, 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":"In projects/dovetail/packages/api/openapi.yaml hat DovetailBeaconStoreService ein sporadisches Problem im React 19-Ablauf. Lies den aktuellen Ablauf und bewerte Ownership, Abbruch und Reihenfolge; ich brauche nur die Analyse.\n\nRandbedingungen:\n- React 19 weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf DovetailBeaconStoreService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um DovetailBeaconStoreService mit React 19 kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"de"}
{"prompt":"DovetailFrostPanelCoordinator: correct, then assess","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Outline a safer DovetailCedarPolicyStore cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-44150\n\n08:02 deploy DovetailDriftConsoleCoordinator 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 DovetailDriftConsoleCoordinator 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":"Fresh release brief for DovetailBeaconStoreCoordinator:\n- primary outcome: separate DovetailBeaconStoreCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/dovetail/config/staging.toml\n- platform constraint: React 19\n- known complication: a feature flag whose default differs between environments\n\nBoth results are required, but they should remain independently reviewable. Make rollback possible without deleting user data; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/dovetail/pkg/cache/lease.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: dovetailbasilrunnerflow::scheduler::LeaseTask::flush\n at ./projects/dovetail/pkg/cache/lease.rs:217:18\n 4: dovetailbasilrunnerflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nFind the source of this DovetailBasilRunnerFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Describe DovetailJuniperCLIService's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The DovetailEchoRegistryService empty state in projects/dovetail/ui/settings/PrivacyPane.tsx needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Zephyr: projects/dovetail/internal/auth/refresh.go now contains DovetailFlintTimelineStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"DovetailRainfallDBCoordinator: restructure, then document","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Release verification found a single stale DovetailOrbitSyncService value; the cause, desired value, and affected assertion are already agreed. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Redis Streams operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Flip DovetailNovaPickerStore's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: DovetailCoralUploadStore works, but staging still carries a setting that production corrected last month. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside DovetailCoralUploadStore\n- make rollback possible without deleting user data\n\nThe relevant code crosses game tooling, data pipelines, macOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"DovetailRavenSessionCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating two validators with subtly different error strings in DovetailCinderAuthStore, 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":"Flip DovetailPrismCacheService's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"DovetailEchoRegistryCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating two validators with subtly different error strings in DovetailBirchMigratorService, 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":"Add a bounded DovetailBirchMigratorStore export stream that resumes from checkpoints, respects cancellation, and exposes queue lag plus terminal failure counters.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'DovetailSummitProxyCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[DovetailSummitProxyCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/dovetail/services/ledger/replay.go:144: error: -[DovetailSummitProxyCoordinatorTests 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 '-[DovetailSummitProxyCoordinatorTests 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\nBring DovetailSummitProxyCoordinator's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"How should DovetailQuartzPlayerService be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"Ticket OPS-44123: retire the legacy replay path for DovetailRainfallDBFlow\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 DovetailRainfallDBFlow 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":"Checkout: A flaky failure around DovetailAmberFilterStore 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 DovetailAmberFilterStore\n- make rollback possible without deleting user data\n\nThe relevant code crosses game tooling, data pipelines, macOS. Prefer evidence from the repository and make any assumption explicit.\n\nA real symptom is present, so follow evidence to a cause rather than stopping at a walkthrough.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Exporter: Ticket OPS-44151: retire the legacy replay path for DovetailMapleQueueCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible DovetailMapleQueueCoordinator 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":"Design handed over a final pass for DovetailWrenExportStore, and the basic data flow in projects/dovetail/app/src/main/SyncWorker.kt already works. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- make rollback possible without deleting user data\n- stay compatible with the existing Playwright deployment\n- keep the work scoped to DovetailWrenExportStore and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Queue DovetailOpalRouterStore's expired sessions","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"# projects/dovetail/src/sync/reconcile.ts\n[worker.dovetailirisbatchcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailirisbatchcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailirisbatchcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailIrisBatchCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44158\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/dovetail/src/sync/reconcile.ts. 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":"PM needs a concise migration note for DovetailIrisBatchFlow, 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":"Give DovetailEchoRegistryStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Scheduler: // projects/dovetail/Sources/App/SessionStore.swift\nfinal class DovetailCoralUploadFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate DovetailCoralUploadFlow'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":"Please resist widening this one: DovetailQuartzPlayerStore works, but staging still carries a setting that production corrected last month. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside DovetailQuartzPlayerStore\n- make rollback possible without deleting user data\n\nThe relevant code crosses game tooling, data pipelines, macOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Memory attributed to DovetailDriftConsoleFlow 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.6,"slice":"core","lang":"en"}
{"prompt":"En projects/dovetail/app/src/main/SyncWorker.kt, DovetailVelaDrawerService tiene un problema intermitente en el flujo de Playwright. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con Playwright\n- conservar compatibilidad y cancelación\n- limitar el cambio a DovetailVelaDrawerService Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con Playwright alrededor de DovetailVelaDrawerService.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"Bring DovetailVelaDrawerStore'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":"Three teams extended DovetailMapleQueueService 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- make rollback possible without deleting user data\n- retain the current React 19 operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Extract DovetailFrostPanelService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"DovetailMoonlitSDKCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Dashboard: projects/dovetail/app/src/main/SyncWorker.kt の DovetailLumenChartService で、Playwright の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- Playwright を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は DovetailLumenChartService のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"DovetailOspreyJobCoordinator needs a paired pass: finish DovetailOspreyJobCoordinator's responsive empty and retry states, plus give the existing implementation a read-only safety pass. Use projects/dovetail/Sources/CLI/Commands/Doctor.swift as the source of truth, preserve the Core Data contract, and avoid unrelated cleanup.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Two deliverables are holding up DovetailOrbitSyncCoordinator. First, find the unknown cause of cancellation being swallowed at the repository boundary. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/dovetail/infra/modules/edge/main.tf, which follows Redis Streams conventions and currently suffers from cancellation being swallowed at the repository boundary. Make rollback possible without deleting user data.\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":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"For DovetailHarborIndexCoordinator, assess ownership and failure handling in projects/dovetail/lib/codec/frame.cc; once that is complete, capture the contract and rollback note for consumers. Work from projects/dovetail/lib/codec/frame.cc, stay with Terraform, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Worker: Incident timeline — INC-44144\n\n08:02 deploy DovetailBirchMigratorFlow 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 DovetailBirchMigratorFlow 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":"Where did DovetailOspreyJobStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"For DovetailCloudReconcilerCoordinator, separate DovetailCloudReconcilerCoordinator's policy from transport without behavior changes; once that is complete, correct the known stale timeout beside it. Work from projects/dovetail/cmd/exporter/main.py, stay with Core Data, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"I inherited DovetailFrostPanelStore and need a careful read of projects/dovetail/pkg/cache/lease.rs 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- make rollback possible without deleting user data\n- stay compatible with the existing React 19 deployment\n- keep the work scoped to DovetailFrostPanelStore and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.\n\nNothing is reported broken, so judge and explain current behavior without inventing a failure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Read projects/dovetail/db/migrations/20260730_events.sql and tell me whether DovetailWillowCodecService can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-44131: retire the legacy replay path for DovetailNovaPickerFlow\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 DovetailNovaPickerFlow 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":"# projects/dovetail/ml/pipeline/features.py\n[worker.dovetailcloudreconcilerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailcloudreconcilerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailcloudreconcilerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailCloudReconcilerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44127\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 DovetailCloudReconcilerFlow'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":"Test Suite 'DovetailLedgerGateFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[DovetailLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/dovetail/workers/thumbnail/consumer.ex:144: error: -[DovetailLedgerGateFlowTests 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 '-[DovetailLedgerGateFlowTests 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\nFind the source of this DovetailLedgerGateFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Simulator: Test Suite 'DovetailAmberFilterCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[DovetailAmberFilterCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/dovetail/workers/thumbnail/consumer.ex:144: error: -[DovetailAmberFilterCoordinatorTests 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 '-[DovetailAmberFilterCoordinatorTests 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\nFinish the visible DovetailAmberFilterCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Summarize the DovetailRainfallDBService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Runbook: Test Suite 'DovetailVelaDrawerCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[DovetailVelaDrawerCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/dovetail/apps/console/routes/usage.svelte:144: error: -[DovetailVelaDrawerCoordinatorTests 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 '-[DovetailVelaDrawerCoordinatorTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Finish the visible DovetailVelaDrawerCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Is there a cleaner way to separate DovetailEmberRelayStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Style DovetailCopperBridgeService's offline state","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Security flagged DovetailIrisBatchStore for a read-only pass because its Playwright 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- make rollback possible without deleting user data\n- retain the current Playwright operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.\n\nNothing is reported broken, so judge and explain current behavior without inventing a failure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two asks around DovetailCraneWorkspaceCoordinator: (1) produce a consumer guide for DovetailCraneWorkspaceCoordinator; (2) correct the known stale timeout beside it. Make rollback possible without deleting user data, and leave a clear boundary between the resulting artifacts or edits.","purpose":"writing","secondary":"quickFix","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"The destination for DovetailKiteSchedulerService is broadly agreed; the missing piece is a reversible route from projects/dovetail/Sources/CLI/Commands/Doctor.swift to that target. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside DovetailKiteSchedulerService\n- make rollback possible without deleting user data\n\nThe relevant code crosses game tooling, data pipelines, macOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Support wants the behavior in projects/dovetail/ml/pipeline/features.py recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"What sequence would let DovetailMicaProfileService adopt React 19 with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Production says DovetailAcornWidgetStore is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Terraform operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.\n\nA real symptom is present, so follow evidence to a cause rather than stopping at a walkthrough.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"DovetailNimbusFormCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Trace: projects/dovetail/config/staging.toml の DovetailMapleQueueFlow で、React 19 の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- React 19 を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は DovetailMapleQueueFlow のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"ja"}
{"prompt":"Move DovetailMapleQueueStore'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":"Compare the old and new DovetailAtlasSearchFlow adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: DovetailSummitProxyService works, but staging still carries a setting that production corrected last month. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside DovetailSummitProxyService\n- make rollback possible without deleting user data\n\nThe relevant code crosses game tooling, data pipelines, macOS. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Diff: projects/dovetail/services/ledger/replay.go 里的 DovetailDeltaCanvasService 最近在 Redis Streams 流程中出现间歇性问题。 请拆分职责并去掉重复，同时保持 API、wire value、顺序和可观察行为不变。\n\n约束：\n- 继续使用 Redis Streams\n- 保持兼容性和取消语义\n- 改动只限于 DovetailDeltaCanvasService","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Profiler: projects/dovetail/infra/modules/edge/main.tf has grown through several launches, and DovetailOrbitSyncStore 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- make rollback possible without deleting user data\n- stay compatible with the existing Redis Streams deployment\n- keep the work scoped to DovetailOrbitSyncStore and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Where did DovetailAsterWebhookService's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Compare DovetailCraneWorkspaceService's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"How should DovetailNovaPickerService be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-44124: finish the compact DovetailHarborIndexFlow filter experience\n\nRoute: /catalog/search\nSource: projects/dovetail/engine/render/atlas.cpp\nFramework: Terraform\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 DovetailHarborIndexFlow'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":"2026-07-30T08:14:11.409Z level=info service=dovetailsprucedaemonflow pod=dovetailsprucedaemonflow-7cf8 request_id=44145 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=dovetailsprucedaemonflow request_id=44145 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=dovetailsprucedaemonflow request_id=44145 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=dovetailsprucedaemonflow request_id=44145 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=dovetailsprucedaemonflow request_id=44145 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=dovetailsprucedaemonflow request_id=44145 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=dovetailsprucedaemonflow request_id=44145 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=dovetailsprucedaemonflow request_id=44145 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\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Reconstruct the DovetailSpruceDaemonFlow 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":"The data is already available in projects/dovetail/db/migrations/20260730_events.sql; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Collapse the DovetailFernSnapshotService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Console: The name pendingAck means two different things across DovetailMarbleTokenFlow's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Split projects/dovetail/ui/settings/PrivacyPane.tsx by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Read projects/dovetail/crates/index/src/segment.rs and tell me whether DovetailGarnetModalService 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":"Map DovetailRainfallDBStore's ownership split","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"projects/dovetail/crates/index/src/segment.rs now contains DovetailBasilRunnerStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Could DovetailMosaicGridStore show the active React 19 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":"diff --git a/projects/dovetail/services/ledger/replay.go b/projects/dovetail/services/ledger/replay.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/dovetail/services/ledger/replay.go\n+++ b/projects/dovetail/services/ledger/replay.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 DovetailQuartzPlayerFlow'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":"Split projects/dovetail/services/ledger/replay.go by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"DovetailSableParserCoordinator: handle the lingering thing","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"DovetailCinderAuthCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-44130\n\n08:02 deploy DovetailOpalRouterFlow 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 DovetailOpalRouterFlow, 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 DovetailAsterWebhookStore migrate incrementally?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"vague-eval","lang":"en"}
{"prompt":"Polish the DovetailCopperBridgeStore toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"DovetailLumenChartCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"On compact widths, DovetailSableParserStore's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Workspace: Split DovetailCedarPolicyService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/dovetail/workers/thumbnail/consumer.ex: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: dovetailravensessionflow::scheduler::LeaseTask::flush\n at ./projects/dovetail/workers/thumbnail/consumer.ex:217:18\n 4: dovetailravensessionflow::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 DovetailRavenSessionFlow 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":"Extract DovetailHarborIndexService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Repository: // projects/dovetail/config/staging.toml\nfinal class DovetailPineMetricsFlowCoordinator {\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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Wire DovetailPineMetricsFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Release verification found a single stale DovetailAtlasSearchService value; the cause, desired value, and affected assertion are already agreed. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Core Data operational envelope\n\nSeveral teams work in this game tooling, data pipelines, macOS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Unifie les validateurs de DovetailCloudReconcilerStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"fr"}
{"prompt":"DovetailAsterWebhookCoordinator needs a paired pass: produce a consumer guide for DovetailAsterWebhookCoordinator, plus give the existing implementation a read-only safety pass. Use projects/dovetail/crates/index/src/segment.rs as the source of truth, preserve the React 19 contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"DovetailQuartzPlayerCoordinator is blocking the next release because a flaky snapshot caused by locale-dependent sorting. I need two concrete outcomes from a single pass: finish DovetailQuartzPlayerCoordinator's responsive empty and retry states, and capture the contract and rollback note for consumers. Use the existing Redis Streams conventions in projects/dovetail/web/components/FilterDrawer.vue; make rollback possible without deleting user data. 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":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"DovetailDeltaCanvasCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-44134\n\n08:02 deploy DovetailSableParserFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the DovetailSableParserFlow 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":"Does DovetailSlateEditorService preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"# projects/dovetail/lib/codec/frame.cc\n[worker.dovetailacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44114\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/dovetail/lib/codec/frame.cc and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"DovetailBasilRunnerCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"DovetailBirchMigratorCoordinator: rethink this area","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Before we approve DovetailGarnetModalStore, assess whether lost focus when the drawer animation finishes is an actual correctness risk or merely confusing structure. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about DovetailMosaicGridService, but the current prose in projects/dovetail/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- make rollback possible without deleting user data\n- stay compatible with the existing React 19 deployment\n- keep the work scoped to DovetailMosaicGridService and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"DovetailLedgerGateCoordinator: polish, then correct","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Is there a cleaner way to separate DovetailMicaProfileStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Pipeline: diff --git a/projects/dovetail/cmd/exporter/main.py b/projects/dovetail/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/dovetail/cmd/exporter/main.py\n+++ b/projects/dovetail/cmd/exporter/main.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Add the bounded DovetailMoonlitSDKFlow 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":"This should remain a deliberately small patch: DovetailDriftConsoleService has one known configuration mistake in projects/dovetail/infra/modules/edge/main.tf, 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- make rollback possible without deleting user data\n- stay compatible with the existing Redis Streams deployment\n- keep the work scoped to DovetailDriftConsoleService and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"For DovetailOpalRouterCoordinator, change DovetailOpalRouterCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, capture the contract and rollback note for consumers. Work from projects/dovetail/infra/modules/edge/main.tf, stay with Redis Streams, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Gateway: projects/dovetail/lib/codec/frame.cc now contains DovetailMarbleTokenStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"DovetailGarnetModalCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Renderer: # projects/dovetail/Sources/CLI/Commands/Doctor.swift\n[worker.dovetailcinderauthflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetailcinderauthflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetailcinderauthflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailCinderAuthFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44142\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 DovetailCinderAuthFlow'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":"Indexer: Split DovetailOpalRouterService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Documente le contrat DovetailLedgerGateService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"fr"}
{"prompt":"diff --git a/projects/dovetail/Sources/App/SessionStore.swift b/projects/dovetail/Sources/App/SessionStore.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/dovetail/Sources/App/SessionStore.swift\n+++ b/projects/dovetail/Sources/App/SessionStore.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\nRead the artifact above as a skeptical reviewer. Is DovetailOspreyJobFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Apparently: Incident timeline — INC-44157\n\n08:02 deploy DovetailAtlasSearchCoordinator 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\nReconstruct the DovetailAtlasSearchCoordinator 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":"Lately: # projects/dovetail/services/ledger/replay.go\n[worker.dovetaildeltacanvasflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.dovetaildeltacanvasflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.dovetaildeltacanvasflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.DovetailDeltaCanvasFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-44135\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/dovetail/services/ledger/replay.go and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"The data is already available in projects/dovetail/Sources/App/SessionStore.swift; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Walk through DovetailCraneWorkspaceStore's reconcile.ts","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Trace DovetailAcornWidgetService's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Oddly: Incident timeline — INC-44110\n\n08:02 deploy DovetailOrbitSyncFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the DovetailOrbitSyncFlow 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":"Currently: // projects/dovetail/Sources/App/SessionStore.swift\nfinal class DovetailKiteSchedulerCoordinatorCoordinator {\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 DovetailKiteSchedulerCoordinator 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":"Sketch the DovetailPineMetricsService migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Drop DovetailPineMetricsStore's unused import","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Today: Incident timeline — INC-44120\n\n08:02 deploy DovetailJuniperCLIFlow 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 DovetailJuniperCLIFlow 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":"Translate the DovetailPrismCacheStore setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Context: Incident timeline — INC-44122\n\n08:02 deploy DovetailCedarPolicyFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the DovetailCedarPolicyFlow 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":"Two engineers disagree about whether DovetailAtlasSearchStore's cache is authoritative. Walk the reads and writes in projects/dovetail/cmd/exporter/main.py and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"We expect DovetailAmberFilterService to outgrow its current Terraform 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- make rollback possible without deleting user data\n- stay compatible with the existing Terraform deployment\n- keep the work scoped to DovetailAmberFilterService and its direct tests\n\nThis repository spans game tooling, data pipelines, macOS; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"DovetailEmberRelayCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ist DovetailLedgerGateStore sicher?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"de"}
data/round2-05.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "a pull request that touches the player's ABR logic. i'd rather understand it than approve it:\n\n@@ -88,14 +88,22 @@ export class AbrController {\n- private pickLevel(bandwidth: number): number {\n- return this.levels.findLastIndex(l => l.bitrate < bandwidth * 0.8)\n- }\n+ private pickLevel(bandwidth: number): number {\n+ const buffer = this.media.buffered.length\n+ ? this.media.buffered.end(0) - this.media.currentTime\n+ : 0\n+ const factor = buffer > 20 ? 0.95 : buffer > 8 ? 0.8 : 0.5\n+ const idx = this.levels.findLastIndex(l => l.bitrate < bandwidth * factor)\n+ if (idx < this.currentLevel - 1) return this.currentLevel - 1\n+ return idx\n+ }\n\nthe stated goal is fewer rebuffers; the risk i can see is that we never drop more than one level at a time", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "our API changelog needs an entry for the stream key header change, with what integrators must do before october", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "the QoE dashboard's session sampler shows twenty random sessions with no way to see what happened in one, which is exactly what you want during an incident. build the session timeline view — events on a time axis, bitrate switches, rebuffers, errors — and decide with me first whether it belongs as a drawer or its own route", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "a tidy-up pass, nothing risky", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "our stream keys appear in the ingest access logs because they're in the path, which security flagged this morning", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "the reconciliation method recomputes an account balance from every journal entry ever posted and then writes a snapshot, and it's called from a page that refreshes every ten seconds. before i touch it i want to know what it costs on our largest account and whether the snapshot write can race with a concurrent posting", "purpose": "review", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "invoice posting throws this maybe twice a week in production, never in test:\n\nSystem.Data.SqlClient.SqlException (0x80131904): Transaction (Process ID 88) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.\n at Ledger.Posting.PostingService.PostAsync(PostingBatch batch, CancellationToken ct) in /src/Ledger.Posting/PostingService.cs:line 212\n at Ledger.Api.Controllers.InvoicesController.Post(InvoiceRequest req) in /src/Ledger.Api/Controllers/InvoicesController.cs:line 88\n at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(...)\n\nClientConnectionId:8f2b1c40-9a11-4c02-b771-041ac0aa7719\nError Number:1205,State:51,Class:13\n\nthe deadlock graph shows two sessions on the same page of `JournalEntries`, both doing an insert then an update to `Accounts.Balance`", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "one currency conversion helper, five callers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "transcode workers keep dying on a subset of uploads and ffmpeg's output is all i have:\n\n[hls @ 0x55d1a2] Opening 'seg_00041.ts' for writing\n[libx264 @ 0x55d3f0] frame= 4118 fps=118 q=28.0 size= 204800kB\n[mpegts @ 0x55d880] Non-monotonous DTS in output stream 0:1; previous: 8412000, current: 8409600; changing to 8412001. This may result in incorrect timestamps in the output file.\n[mpegts @ 0x55d880] Non-monotonous DTS in output stream 0:1; previous: 8412001, current: 8409601; changing to 8412002.\n[aac @ 0x55e110] Queue input is backward in time\nav_interleaved_write_frame(): Invalid argument\n[hls @ 0x55d1a2] Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument\nConversion failed!\n\nexit status 1, worker restarts, next attempt fails the same way. always the same 40 or so source files", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "extension breaks on exactly one customer's intranet and their IT sent us the console:\n\nUncaught (in promise) Error: Extension context invalidated.\n at chrome-extension://hkpmbaflnkkcgnbjcplkflmpjeaeblnc/content.js:1:44112\nRefused to connect to 'https://api.lumenclip.io/v1/sync' because it violates the following Content Security Policy directive: \"connect-src 'self' https://intranet.corp.example\"\ncontent.js:1 Uncaught (in promise) TypeError: Failed to fetch\nservice-worker.js:1 Unchecked runtime.lastError: The message port closed before a response was received.\nservice-worker.js:1 Uncaught (in promise) Error: No tab with id: 4118.\n\nmanifest v3, and this works on every other site we've tried", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "CDN origin sees a thundering herd every ten minutes and i can't work out from these logs whether it's us or them:\n\n11:00:00 GET /hls/8812/master.m3u8 200 cache=MISS age=0 origin=142ms\n11:00:00 GET /hls/8812/master.m3u8 200 cache=MISS age=0 origin=141ms\n11:00:00 GET /hls/8812/master.m3u8 200 cache=MISS age=0 origin=188ms\n(… 1,204 identical lines in the same second …)\n11:00:01 GET /hls/8812/720p/seg_00041.ts 200 cache=HIT age=8\n11:10:00 GET /hls/8812/master.m3u8 200 cache=MISS age=0 origin=904ms\n11:10:00 GET /hls/8812/master.m3u8 500 cache=MISS origin=timeout\n\ncache-control on the playlist is max-age=600, and the players all refresh on a fixed schedule", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "extension's service worker keeps getting killed mid-sync, chrome's internals page shows:\n\nService worker registration: chrome-extension://hkpmbaflnkkcgnbjcplkflmpjeaeblnc/\nStatus: STOPPED\nRunning status: STOPPED\nLast activity: 2026-07-29 11:04:41 (32s)\nTermination reason: idle timeout after 30s\nPending events: 2 (alarm 'sync', message from tab 4118)\n\nlog before termination:\n [sync] starting, 41 clips pending\n [sync] uploaded 12/41\n [sync] worker suspended\n [sync] starting, 29 clips pending\n [sync] uploaded 9/29\n\nevery restart re-uploads the ones that were in flight", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "ingest API's public docs are a curl example and nothing else. this is what the handler accepts:\n\nPOST /v1/ingest/{stream_key}\n content-type: application/octet-stream or multipart/form-data\n headers: X-Segment-Sequence (required, monotonic per stream), X-Segment-Duration-Ms (required),\n X-Discontinuity (optional, \"1\" to mark a discontinuity), Content-MD5 (optional but checked when present)\n behaviour: out-of-order sequences within 3 are buffered for up to 2s; beyond that they are rejected with 409\n a repeated sequence with the same Content-MD5 is a no-op 200; with a different one it is a 409\n segments over 30s are rejected with 413; the stream is terminated after 3 consecutive rejections\n auth is the stream key in the path, which is why it must never appear in logs or referrer headers\n\nwrite the reference page, and be explicit about the retry semantics because every partner gets them wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "player's event emitter has grown three ways to subscribe and i want one, without breaking integrators:\n\nplayer.on('ready', cb) // 3.x style, still used by everyone\nplayer.addEventListener('ready', cb) // added in 4.0 to look DOM-like\nplayer.events.subscribe('ready', cb) // added in 4.2 by someone who likes rxjs\n\ninternally all three end up in the same map, except `events.subscribe` returns an unsubscribe function and the other two don't, and `addEventListener` supports the `once` option which the others ignore", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "QoE dashboard spec from our SRE, build it in the internal console:\n\nQoE overview\n- Time range picker (15m / 1h / 6h / 24h / 7d), defaults to 1h, persists per user.\n- Four headline tiles: rebuffer ratio, startup time p95, error rate, average bitrate. Each with a delta against the previous period and a sparkline.\n- Breakdown table: by CDN edge, by ISP, by player version, switchable with a segmented control. Sortable columns, 20 rows with a \"show all\".\n- Session sampler: 20 random sessions matching the current filters, click to open a session timeline with events plotted on a time axis.\n- Live streams get a separate section with a row per stream, ordered by concurrent viewers, updating every 10 seconds.\n- Anything above the rebuffer threshold is highlighted, but the threshold is configurable and must not be hardcoded.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "live playlist TTL to 2 seconds", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "what does `scenecut: 0` cost us?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "is the outbox write in the same transaction?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "invoice PDF footer shows last year's VAT id", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "one fetch wrapper for the extension", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "month-end close produced numbers that don't tie out, and this is the reconciliation report:\n\nAccount GL Balance Subledger Difference\n1200 AR 1,204,118.42 1,204,118.42 0.00\n2100 AP 882,441.10 882,437.60 3.50\n4000 Revenue 2,118,904.00 2,118,904.00 0.00\n5000 COGS 1,441,220.18 1,441,220.18 0.00\n2200 VAT 188,412.55 188,409.05 3.50\n\nJournal 88412 posted 2026-07-31 23:59:58 by [system]\nJournal 88413 posted 2026-08-01 00:00:02 by [system]\n\nboth journals are for the same invoice batch, and the 3.50 is a rounding line that appears once in the subledger and twice in the GL", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "ADR someone wrote for the packager rewrite. does the reasoning hold up?\n\n## Context\nThe packager keeps one goroutine per live stream, holding the muxer state and the playlist in memory. At 300 streams this is fine; at 3,000 it will not be.\n\n## Decision\nMove packaging into a stateless service. Segment state goes to redis, playlists are rendered on demand from redis, and any instance can serve any stream.\n\n## Consequences\n- Horizontal scaling becomes trivial.\n- Redis becomes a hard dependency on the live path.\n- Playlist rendering moves from once per segment to once per request.\n\n## Alternatives considered\nSharding by stream id was rejected as \"operationally complex\".", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "VAT rounding helper, which is now the subject of an audit finding:\n\npublic static decimal RoundVat(decimal net, decimal rate, RoundingMode mode = RoundingMode.HalfUp)\n{\n var raw = net * rate;\n return mode switch\n {\n RoundingMode.HalfUp => Math.Round(raw, 2, MidpointRounding.AwayFromZero),\n RoundingMode.HalfEven => Math.Round(raw, 2, MidpointRounding.ToEven),\n RoundingMode.Truncate => Math.Truncate(raw * 100) / 100,\n _ => Math.Round(raw, 2)\n };\n}\n\ncredit notes pass a negative net; the default mode is used almost everywhere; and the German tax rules we're being assessed against say to round the absolute value", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "support handover notes about the extension, needs to become a real troubleshooting page:\n\n- \"extension context invalidated\" almost always means they updated the extension while a tab was open, tell them to reload the tab\n- clips not syncing: check the service worker is alive in chrome://serviceworker-internals, it dies after 30s idle and our alarm is set to 5 minutes\n- corporate networks with a strict CSP block our api entirely, there is no workaround, they need to allowlist api.lumenclip.io\n- if the popup is blank, it's usually a failed fetch of the clip list; the popup has no error state at all\n- duplicated clips happen when the worker restarts mid-upload, we dedupe server-side within an hour\n- the \"sign in again\" loop is a cookie partitioning thing on chrome 121+, resolved by opening the site once in the same profile", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "internal wiki page for the close process is three years old. reality according to the team:\n\n- close starts when the last bank statement is imported, usually the 2nd or 3rd\n- the revaluation job must run before any accruals are posted, and it's manual\n- there's a checklist in a spreadsheet that four people maintain differently\n- the \"period lock\" button doesn't stop the system journals, which is how we ended up with entries dated after the lock\n- reopening a period requires a database update, there is no UI for it\n- the whole thing takes 4-6 days and the finance team works weekends for it\n\nwrite the page as it should be, and flag the two things that are process problems rather than documentation problems", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "test project has three ways of building an invoice and every new test picks one at random:\n\nvar invoice = new Invoice { CustomerId = 1, Lines = { new InvoiceLine { Net = 100m, Vat = 19m } } };\n\nvar invoice = InvoiceBuilder.New().ForCustomer(1).WithLine(100m, TaxCode.Standard).Build();\n\nvar invoice = TestData.Invoices.Simple(); // fixture file, 4 hardcoded invoices\n\nabout 400 tests between them; the builder is the newest and the only one that computes VAT the way production does", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "finance team's list of what the legacy billing service still does, and we want it gone by december:\n\n- recurring invoice generation for 1,400 subscriptions on the old plan structure\n- the dunning schedule (3, 7, 14 days) including the emails, which use its own templates\n- revenue recognition postings, which the new service does differently and finance hasn't signed off on\n- a nightly export to the tax filing provider, in a fixed-width format nobody remembers the spec for\n- the customer portal's invoice PDF, generated by a library that only exists in that codebase\n- roughly 200 stored procedures, of which we believe 40 are actually called\n\nwhat's the order, what's the risk, and where would you cut scope", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "design doc stub for the DVR change, i want the thinking before the implementation:\n\nCurrent: DVR window is 2 hours, held as segments in the packager's memory plus S3, playlist rendered from an in-memory ring buffer.\nAsked for: 12 hours, with seeking anywhere in the window, on live streams with up to 40,000 concurrent viewers.\nConstraints: segment storage cost triples if we keep the current bitrate ladder for the whole window; the playlist for a 12-hour window is about 10,000 entries and clients parse it on every refresh; our current CDN caches playlists for 2 seconds; and a stream that restarts mid-event must not lose the earlier part of the window.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "tax lines wrap badly at 1280px", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "docs for the ingest retry semantics", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "why is origin seeing 1200 playlist requests/s?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "packager thing again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "invoices, the usual", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "ledger domain has accumulated three years of small decisions and is now a single project with sixty classes, no obvious seams, and a test suite that needs a database. i keep being told to \"just refactor it\", but i'd rather agree a target shape first: what the modules should be, what depends on what, and which pieces we'd move in what order without stopping feature work", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "player SDK's events table in our docs lists an event that never existed and omits the two that every integrator actually wants for quality metrics. correct the table, explain the difference between a recoverable error and a fatal one, and note which events only fire on live streams — integrators are web developers who will copy whatever we publish", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "an auditor has asked six questions about journal immutability, period locks, numbering gaps, rate sourcing, retention and attachment deletion, and answering them properly means writing the controls document we never had. work each answer out from the code rather than from what we'd like to be true, and mark anything you can't substantiate", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "segment uploader retries with a sleep of attempt seconds, which is zero on the first retry, and it retries with the same reader for live segments", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "we need a position on whether the extension should keep its own sync engine or move to the same one the web app uses", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "CDN config has the playlist TTL wrong for live and it's a two-line change, but i want a sanity check:\n\ncurrent:\n - path: \"*.m3u8\"\n cache: { ttl: 600, stale_while_revalidate: 0 }\n\nproposed:\n - path: \"/live/*/*.m3u8\"\n cache: { ttl: 2, stale_while_revalidate: 4 }\n - path: \"/vod/*/*.m3u8\"\n cache: { ttl: 86400, stale_while_revalidate: 600 }\n\nlive playlists are rewritten every 4 seconds, VOD ones never change once published, and origin currently sees about 1,200 requests per second on playlists alone", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "extension talks to the API from three places, each with its own auth handling:\n\n// content.js\nconst res = await fetch(`${API}/v1/clips`, { headers: { Authorization: `Bearer ${token}` } })\n\n// service-worker.js\nconst res = await fetch(`${API}/v1/sync`, {\n method: 'POST',\n credentials: 'include',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify(payload),\n})\n\n// popup.js\nconst token = await chrome.storage.local.get('token')\nconst res = await fetch(`${API}/v1/clips?limit=50`, { headers: { Authorization: `Bearer ${token.token}` } })\n\none of them uses cookies, two use a bearer token, and only the popup handles a 401", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "live badge needs a text label", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "QoE tiles should show a delta", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "transcode fails on 40 specific files", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "ingest API's retry semantics are the single biggest source of partner integration bugs — repeated sequences, buffering windows, when a 409 is fatal and when it isn't — and none of it is written down anywhere outside the handler. write the reference page a partner engineer could implement against without asking us a single question, including a worked example of a reconnect after a network drop", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "extension's permissions are far wider than what it does, and the store review is friday. work out the minimum set from the code, then narrow the manifest and content script matches accordingly — and tell me what functionality we lose, if any", "purpose": "planning", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "what happens to an in-flight ingest when a stream key is rotated — does the session survive or drop?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "is the reconciliation method safe to call from a page that refreshes every ten seconds on an account with 300k entries", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "player's control bar hides itself after three seconds regardless of whether the pointer is still over it, and on touch devices it disappears while you're reaching for the seek bar. rework the auto-hide so it respects hover and recent touch, stays visible whenever a control has focus, and never hides while the settings menu is open", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "pprof from the packager service, memory climbs until the pod is killed:\n\nShowing nodes accounting for 6.14GB, 94.12% of 6.52GB total\n flat flat% sum% cum cum%\n 3.88GB 59.51% 59.51% 3.88GB 59.51% bytes.growSlice\n 1.42GB 21.78% 81.29% 5.30GB 81.29% lumen/packager.(*Muxer).WriteSegment\n 0.61GB 9.36% 90.65% 0.61GB 9.36% lumen/packager.(*Playlist).Render\n 0.23GB 3.53% 94.18% 0.23GB 3.53% encoding/json.Marshal\n\ngoroutines: 41,882\ntop goroutine stack:\n lumen/packager.(*Session).watch\n /src/packager/session.go:141 +0x88\n created by lumen/packager.(*Manager).Start in goroutine 1\n\nwe start one session per live stream and we have about 300 live streams", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "seit dem letzten Deploy stimmen die Umsatzsteuer-Beträge bei Gutschriften nicht mehr:\n\nRechnung 88412 netto 1.000,00 USt 19% = 190,00 brutto 1.190,00 ✓\nGutschrift 88413 netto -1.000,00 USt 19% = -190,00 brutto -1.190,00 ✓\nRechnung 88420 netto 840,34 USt 19% = 159,66 brutto 1.000,00 ✓\nGutschrift 88421 netto -840,34 USt 19% = -159,67 brutto -1.000,01 ✗\n\nDie Differenz von einem Cent tritt nur bei Beträgen auf, die aus einem Bruttobetrag zurückgerechnet wurden. Betroffen sind etwa 200 Belege seit Freitag.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "a broadcaster wants a twelve-hour DVR window and we currently do two, which sounds like a config change until you consider that the playlist becomes ten thousand entries that every client re-parses on each refresh, that keeping the full bitrate ladder for twelve hours triples our storage bill, and that a stream restarting mid-event must not lose what came before. i want the shape of a solution and the trade-offs written down before anyone starts moving segments around", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "our on-call covers ingest, packaging and delivery with alerts written by three different people, and half of them page for things that self-resolve", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "the proration calculation exists four times with four different day-count conventions, and finance considers only the subscriptions one correct. consolidate onto it, work out which historical invoices would have been different under each of the others, and be explicit about whether we're correcting anything retroactively or only going forward", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "a walkthrough of how an invoice becomes a journal entry, naming the services involved, would help before i touch posting", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "our clip editor's trim handles are mouse-only, they don't snap on touch, and there's no keyboard path to adjusting a trim point at all, which came up in the same accessibility review as the player controls. make the handles work with pointer events across devices, keep the 0.1 second snapping, and add the arrow-key nudging the spec asked for", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "the extension's storage is split across chrome.storage.local, chrome.storage.sync and an indexeddb wrapper with no rule about what goes where, which is part of why the sign-in loop happens on some profiles. rationalise it into one layer with an explicit policy, then document the policy where the next person will find it", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "invoice list needs saved filters per user, since finance re-applies the same four every morning", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "one more sweep", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "nightly revaluation job silently produced nothing for two currencies:\n\n[00:15:02] revaluation started, base=EUR, rates_as_of=2026-07-30\n[00:15:02] loaded 41 currencies from provider\n[00:15:03] revaluing 1,204 open items in USD ... 1,204 posted\n[00:15:07] revaluing 882 open items in GBP ... 882 posted\n[00:15:09] revaluing 118 open items in CHF ... 0 posted\n[00:15:09] revaluing 41 open items in SEK ... 0 posted\n[00:15:10] revaluation complete, 2,086 postings, 0 errors\n\nCHF and SEK rates came back from the provider as strings rather than numbers this time, and nothing complained", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "i'm meant to approve this before the release, and the retry loop bothers me:\n\nfunc (u *Uploader) Put(ctx context.Context, key string, r io.Reader) error {\n\tfor attempt := 0; attempt < 5; attempt++ {\n\t\terr := u.s3.Upload(ctx, key, r)\n\t\tif err == nil {\n\t\t\treturn nil\n\t\t}\n\t\tif errors.Is(err, context.Canceled) {\n\t\t\treturn err\n\t\t}\n\t\ttime.Sleep(time.Duration(attempt) * time.Second)\n\t}\n\treturn fmt.Errorf(\"upload %s failed after 5 attempts\", key)\n}\n\ncallers pass an *os.File for small segments and a pipe reader for live ones", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "posting service's transaction scope, which i inherited. is this doing what the comment claims?\n\n// Posts the batch atomically; either every entry lands or none do.\npublic async Task PostAsync(PostingBatch batch, CancellationToken ct)\n{\n using var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);\n foreach (var entry in batch.Entries)\n {\n await _entries.InsertAsync(entry, ct);\n await _accounts.AdjustBalanceAsync(entry.AccountId, entry.Amount, ct);\n }\n await _outbox.EnqueueAsync(new BatchPosted(batch.Id), ct);\n scope.Complete();\n}\n\n_entries and _accounts use separate DbContext instances from DI, and _outbox writes to the same database", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "manifest for our extension, about to go through store review. anything here that will bounce?\n\n{\n \"manifest_version\": 3,\n \"name\": \"Lumen Clip\",\n \"version\": \"3.4.1\",\n \"permissions\": [\"tabs\", \"storage\", \"scripting\", \"webRequest\", \"cookies\", \"downloads\"],\n \"host_permissions\": [\"<all_urls>\"],\n \"background\": { \"service_worker\": \"service-worker.js\", \"type\": \"module\" },\n \"content_scripts\": [{ \"matches\": [\"<all_urls>\"], \"js\": [\"content.js\"], \"run_at\": \"document_idle\" }],\n \"externally_connectable\": { \"matches\": [\"*://*.lumenclip.io/*\"] },\n \"content_security_policy\": { \"extension_pages\": \"script-src 'self' 'wasm-unsafe-eval'; object-src 'self'\" }\n}\n\nwe only actually need to read the page title and the video element's src", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "cache rules from our CDN config, and origin load has doubled since we shipped them:\n\nrules:\n - path: \"*.m3u8\"\n cache: { ttl: 600, stale_while_revalidate: 0, key: [path, query] }\n - path: \"*.ts\"\n cache: { ttl: 86400, stale_while_revalidate: 60, key: [path] }\n - path: \"/api/*\"\n cache: { ttl: 0 }\n - path: \"*\"\n cache: { ttl: 300, key: [path, query, header:Authorization] }\n\nlive playlists change every 4 seconds; VOD playlists never change after publish; both match the first rule", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "这是我们对账服务的核心方法，接手之后一直没敢动，先帮我看看它到底在做什么、有没有隐患：\n\npublic decimal Reconcile(int accountId, DateTime asOf)\n{\n var entries = _db.JournalEntries\n .Where(e => e.AccountId == accountId && e.PostedAt <= asOf)\n .ToList();\n var balance = entries.Sum(e => e.Amount);\n var snapshot = _db.Balances.FirstOrDefault(b => b.AccountId == accountId && b.AsOf == asOf.Date);\n if (snapshot == null)\n {\n _db.Balances.Add(new Balance { AccountId = accountId, AsOf = asOf.Date, Amount = balance });\n _db.SaveChanges();\n }\n else if (snapshot.Amount != balance)\n {\n snapshot.Amount = balance;\n _db.SaveChanges();\n }\n return balance;\n}\n\n这个方法在报表页面上每次刷新都会被调用，账户的分录有几十万条", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "zh"}
{"prompt": "notas de la sesión de diseño, hay que convertirlas en el documento que se manda a los clientes:\n\n- el nuevo modelo de facturación recurrente permite ciclos mensuales, trimestrales y anuales\n- el prorrateo se calcula por días naturales, no por días laborables\n- si un cliente cambia de plan a mitad de ciclo se emite una nota de crédito por la parte no consumida\n- los impuestos se recalculan siempre en la fecha de emisión, nunca en la fecha del cambio\n- las facturas fallidas se reintentan tres veces: a los 3, 7 y 14 días\n- tras el tercer intento la suscripción pasa a estado suspendido, no cancelado\n- la reactivación no genera una factura nueva, se reintenta la pendiente\n\nel público son administradores financieros, no técnicos", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "es"}
{"prompt": "changelog for the player SDK, from the commits since 4.2:\n\n88f21c0 feat(abr): buffer-aware level selection\n41ba190 fix(hls): handle discontinuity tags in live playlists\nc0aa774 fix(abr): don't drop more than one level per switch\n2e91b45 feat(api): expose `currentLevel` and `levels` on the player instance\naa30f19 fix(ios): audio desync after backgrounding\n9c1d004 perf: reuse the segment buffer instead of allocating per segment\n4410bb7 chore: drop support for Safari 15\nb77e910 fix(dvr): seeking past the live edge no longer stalls\n30cc219 docs: correct the events table\n\nintegrators are web developers; breaking changes need to be obvious and there is one", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "auditor's question list arrived, and answering it well is basically writing the doc we never wrote:\n\n1. How are journal entries prevented from being modified after posting?\n2. Which roles can post to a closed period, and how is that recorded?\n3. Describe the numbering scheme for journals and how gaps are prevented.\n4. How are foreign currency rates sourced, stored and evidenced?\n5. What is the retention period for the audit trail, and where is it stored?\n6. Can a user delete an attachment from a posted invoice?\n\nanswer each from the code, and write it as a controls document rather than a list of replies", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "runbook for a stuck live stream is currently a slack thread. what we actually do:\n\n- viewer reports a stall; first check is the packager session for that stream id in grafana\n- if `segment_lag_seconds` is above 12 the ingest side is behind, and that's the encoder's problem, not ours\n- if lag is fine but the playlist isn't advancing, the muxer goroutine is wedged; `lumenctl session restart <id>` recovers it in about 8 seconds with a visible glitch\n- never restart the whole packager pod during a live event, you take out every stream on that instance\n- if redis latency is above 5ms the playlist renders will queue and everything looks broken\n- after any restart, check the DVR window is intact before telling the customer it's fixed", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "o texto atual do aviso de descontinuação está mau e sai amanhã:\n\n\"A partir de 1 de Outubro a versão 3 da API de ingestão deixará de estar disponível. Os clientes devem migrar para a versão 4. A versão 4 tem várias diferenças. Contacte o suporte para mais informações.\"\n\nfactos: a v3 aceita segmentos até 30s, a v4 até 10s; a v3 usa a chave no caminho, a v4 usa um cabeçalho; a v4 exige o Content-MD5; existem 340 clientes na v3, dos quais 12 representam 80% do tráfego; a data limite é firme por causa do desligamento do CDN antigo\n\nreescreve o aviso e o email para os 12 clientes grandes", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "pt"}
{"prompt": "SDK's events table in the docs versus what the code emits. reconcile them into one correct table:\n\ndocs list: ready, play, pause, seeking, seeked, levelswitch, error, ended\ncode emits: ready, play, pause, seeking, seeked, levelSwitching, levelSwitched, error, fatalError, ended, rebufferStart, rebufferEnd, dvrWindowChanged\n\nnotes: `levelswitch` in the docs never existed; `error` is non-fatal and recoverable while `fatalError` tears down the player; `rebufferStart`/`rebufferEnd` were added in 4.1 and are what everyone actually wants for QoE metrics; `dvrWindowChanged` only fires on live streams", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "dotnet build warnings, treat-warnings-as-errors goes on next sprint:\n\n/src/Ledger.Posting/PostingService.cs(88,17): warning CS8602: Dereference of a possibly null reference.\n/src/Ledger.Posting/PostingService.cs(212,9): warning CS4014: Because this call is not awaited, execution of the current method continues before the call is completed.\n/src/Ledger.Domain/Money.cs(41,26): warning CS0659: 'Money' overrides Object.Equals(object o) but does not override Object.GetHashCode()\n/src/Ledger.Api/Controllers/InvoicesController.cs(66,13): warning CS0168: The variable 'ex' is declared but never used\n/src/Ledger.Infrastructure/RateProvider.cs(22,32): warning CS8618: Non-nullable property 'Client' must contain a non-null value when exiting constructor\n\n5 warnings, and CS4014 in a posting service is the one keeping me awake", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "npm audit on the extension, and the store review is on friday:\n\n# npm audit report\n\nesbuild <=0.24.2\nModerate: esbuild enables any website to send requests to the development server\nfix available via `npm audit fix --force`\nWill install [email protected], which is a breaking change\n\nws 8.0.0 - 8.17.0\nHigh: ws affected by a DoS when handling a request with many HTTP headers\nfix available via `npm audit fix`\n\nzod 3.22.0 - 3.23.7\nLow: inefficient regular expression complexity\nfix available via `npm audit fix`\n\n3 vulnerabilities (1 low, 1 moderate, 1 high)\n\nesbuild is a devDependency, ws is used by the dev server only, zod ships in the bundle", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "nginx config for the origin, someone noticed this while debugging the herd:\n\nproxy_cache_path /var/cache/nginx/segments levels=1:2 keys_zone=segments:100m max_size=200g inactive=24h;\n\nupstream packager {\n server packager-0.packager:8080 max_fails=3 fail_timeout=10s;\n server packager-1.packager:8080 max_fails=3 fail_timeout=10s;\n keepalive 64;\n}\n\nlocation ~ \\.m3u8$ {\n proxy_pass http://packager;\n proxy_cache off;\n proxy_read_timeout 5s;\n add_header Cache-Control \"max-age=600\";\n add_header X-Cache-Status $upstream_cache_status;\n}\n\nlocation ~ \\.ts$ {\n proxy_pass http://packager;\n proxy_cache segments;\n proxy_cache_valid 200 1d;\n proxy_cache_lock on;\n proxy_cache_lock_timeout 5s;\n proxy_cache_use_stale updating error timeout;\n add_header Cache-Control \"public, max-age=86400, immutable\";\n add_header X-Cache-Status $upstream_cache_status;\n}\n\nthe playlist location has no proxy_cache_lock, no upstream caching at all, and a 5 second read timeout that the packager occasionally exceeds under load", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "github actions matrix for the .NET service, and the windows leg has been broken for a month:\n\nstrategy:\n matrix:\n os: [ubuntu-latest, windows-latest]\n dotnet: ['8.0.x', '9.0.x']\nsteps:\n - uses: actions/setup-dotnet@v4\n with: { dotnet-version: ${{ matrix.dotnet }} }\n - run: dotnet test --logger trx --collect:\"XPlat Code Coverage\"\n\nfailure on windows:\n error MSB4019: The imported project \"C:\\Program Files\\dotnet\\sdk\\9.0.100\\Sdks\\Microsoft.NET.Sdk\\Sdk.props\" was not found\n error NU1101: Unable to find package Ledger.Testing.Fixtures\n\nnobody deploys to windows and nobody has fixed it either", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "两个环境的转码参数不一样，线上的画质投诉可能就是这个原因：\n\n# staging/transcode.yaml\ntranscode:\n preset: slow\n crf: 21\n keyint: 48\n min_keyint: 48\n scenecut: 40\n bframes: 3\n audio_codec: aac\n audio_bitrate: 192k\n ladder: [240p, 480p, 720p, 1080p]\n two_pass: true\n\n# production/transcode.yaml\ntranscode:\n preset: veryfast\n crf: 26\n keyint: 250\n min_keyint: 25\n scenecut: 0\n bframes: 0\n audio_codec: aac\n audio_bitrate: 96k\n ladder: [240p, 480p, 720p, 1080p]\n two_pass: false\n\n# 相关指标（过去 7 天）\n 平均转码时长/分钟素材：staging 44s，production 11s\n 画质投诉工单：本月 38 件，去年同期 4 件\n 出网流量：同比 -22%\n\n线上是去年为了赶一个活动临时改的，之后就没人动过，也没有人记得当时的取舍", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "zh"}
{"prompt": "feature flag defaults across our three services, one of these is not like the others:\n\n# packager/config/flags.yaml\nflags:\n buffer_aware_abr: true\n redis_playlists: false\n dvr_enabled: true\n multi_cdn_selection: false\n segment_reuse_buffer: true\n\n# api/config/flags.yaml\nflags:\n buffer_aware_abr: true\n redis_playlists: true\n dvr_enabled: true\n multi_cdn_selection: false\n segment_reuse_buffer: true\n\n# player-config service — what clients actually receive\nflags:\n buffer_aware_abr: false\n redis_playlists: false\n dvr_enabled: true\n multi_cdn_selection: false\n segment_reuse_buffer: false\n\n# experiment dashboard, week 3\n rebuffer ratio, control: 1.82%\n rebuffer ratio, treatment: 1.81%\n sessions in treatment: 412,118\n\nwe've been measuring the ABR change for three weeks and wondering why the numbers didn't move", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "same currency conversion appears in five services with four different rounding behaviours. one implementation, please:\n\n// billing\nvar converted = Math.Round(amount * rate, 2, MidpointRounding.AwayFromZero);\n\n// reporting\nvar converted = decimal.Round(amount * rate, 2);\n\n// api\nvar converted = (decimal)Math.Round((double)(amount * rate), 2);\n\n// export\nvar converted = Math.Floor(amount * rate * 100) / 100;\n\n// legacy\nvar converted = amount * rate; // rounded at render time, sometimes\n\nthe billing one is the behaviour the auditors signed off on", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "this session manager holds four responsibilities and a mutex. i want the same behaviour, decomposed:\n\ntype Manager struct {\n\tmu sync.Mutex\n\tsessions map[string]*Session\n\tmuxers map[string]*Muxer\n\tplaylists map[string]*Playlist\n\tuploads map[string]*Uploader\n\tmetrics *Metrics\n}\n\nfunc (m *Manager) Start(id string) error {\n\t// creates the session, muxer, playlist and uploader\n\t// starts a goroutine per session that watches for segments\n\t// updates metrics inline\n\t// on error, tears down whichever of the four were created\n}\n\nfunc (m *Manager) Stop(id string) error { /* the reverse, holding mu the whole time */ }\n\nStop holds the mutex while waiting for goroutines to finish, which is why a slow upload blocks every other stream", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "controller does validation, mapping, business logic and persistence. same API contract, better shape:\n\n[HttpPost]\npublic async Task<IActionResult> Post(InvoiceRequest req)\n{\n if (req.Lines == null || req.Lines.Count == 0) return BadRequest(\"lines required\");\n if (req.Lines.Any(l => l.Quantity <= 0)) return BadRequest(\"quantity must be positive\");\n var customer = await _db.Customers.FindAsync(req.CustomerId);\n if (customer == null) return NotFound();\n var invoice = new Invoice { CustomerId = customer.Id, IssuedAt = DateTime.UtcNow };\n foreach (var l in req.Lines)\n {\n var net = l.Quantity * l.UnitPrice;\n var vat = RoundVat(net, TaxTable.RateFor(customer.Country, l.TaxCode));\n invoice.Lines.Add(new InvoiceLine { Net = net, Vat = vat, ... });\n }\n invoice.Total = invoice.Lines.Sum(x => x.Net + x.Vat);\n _db.Invoices.Add(invoice);\n await _db.SaveChangesAsync();\n await _mail.SendInvoiceAsync(invoice);\n return CreatedAtAction(nameof(Get), new { id = invoice.Id }, InvoiceDto.From(invoice));\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "quatre variantes du même calcul de prorata dans le code de facturation :\n\n// subscriptions/proration.cs\nvar days = (end - start).Days;\nvar factor = (decimal)days / DateTime.DaysInMonth(start.Year, start.Month);\n\n// billing/upgrade.cs\nvar factor = (decimal)(end - start).TotalDays / 30m;\n\n// api/preview.cs\nvar factor = (decimal)(end - start).Days / (decimal)(cycleEnd - cycleStart).Days;\n\n// legacy/prorate.cs\nvar factor = Math.Round((decimal)(end - start).Days / 30.4375m, 4);\n\ncelle de subscriptions est celle que la finance considère correcte", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "fr"}
{"prompt": "quarterly input from the business, and i need to turn it into something sequenced:\n\n- a broadcaster wants live DVR with a 12-hour window, currently we do 2 hours\n- finance wants us off the legacy billing service by december, it's the last thing on the old database\n- the player SDK has to support the new codec by Q1 or we lose a deal\n- support says the top three tickets are all about the extension's sign-in loop\n- the packager rewrite is half done and blocked on a decision about redis\n- one backend engineer leaves in september, the replacement starts in november\n- we have a CDN contract renewal in october that changes our cost model per GB", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "ticket that needs a plan rather than an implementation:\n\nLMN-812 — Multi-CDN delivery\nWe currently deliver from a single CDN. Contract renewal in October gives us an opportunity to go multi-CDN, and one large customer has asked for it explicitly after our June incident. Requirements as understood: per-session CDN selection, ability to shift traffic during an incident within minutes, consistent QoE measurement across providers, and no change to how customers embed the player. Unknowns: token authentication differs between the two candidate providers, cache warming would double our origin egress, and our QoE metrics are currently derived from one provider's logs.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "design handoff for the clip editor in the extension popup, build it:\n\nClip editor (popup, 400x600)\n- Video preview at the top, 16:9, poster from the captured frame, no controls beyond play/pause.\n- Trim bar under the preview: 48px tall, waveform if we have audio, two draggable handles, current position as a 2px line. Handles snap to 0.1s and show a time label while dragging.\n- Title field: single line, autofocused, character counter at 80, error state past 100.\n- Tag input: chips with an X, autocomplete from the user's recent tags, enter or comma commits.\n- Footer: \"Save clip\" primary, \"Discard\" text button, both disabled while uploading, with a determinate progress bar replacing the footer during upload.\n- Offline: the editor still works, the save button says \"Save for later\" and the clip queues.\n- Keyboard: space toggles playback, arrow keys nudge the nearest handle by 0.1s, shift+arrow by 1s.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "UI-Abnahme für die Rechnungsansicht, bitte umsetzen:\n\nRechnungsansicht (Desktop, ab 1280px)\n- Kopfbereich: Rechnungsnummer (20px, halbfett), Status-Badge rechts daneben (Entwurf / Gebucht / Storniert / Überfällig).\n- Zwei Spalten: links Rechnungsempfänger, rechts Datum, Fälligkeit, Zahlungsbedingungen. Beschriftungen 12px grau, Werte 14px.\n- Positionstabelle: Menge rechtsbündig, Einzelpreis rechtsbündig, Steuersatz zentriert, Betrag rechtsbündig und fett. Zeilenhöhe 40px.\n- Summenblock rechts unten: Netto, Steuer je Satz einzeln aufgeführt, Brutto in 18px halbfett.\n- Bei stornierten Rechnungen liegt ein diagonales Wasserzeichen über der Tabelle, die Werte bleiben lesbar.\n- Aktionen oben rechts: Buchen, PDF, Stornieren. Buchen ist deaktiviert, wenn die Periode geschlossen ist, mit Tooltip.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "de"}
{"prompt": "accessibility report for the player's controls, from a customer's audit:\n\n- The play/pause button toggles its icon but not its accessible name, so it always announces \"play\".\n- The seek bar is a div with mouse handlers; keyboard users cannot seek at all.\n- Volume is a custom slider with no role, no aria-valuenow, and no keyboard support.\n- The captions menu opens on hover only and is unreachable by keyboard.\n- Focus is never visible on any control; the outline is removed globally in the SDK's stylesheet.\n- The live indicator conveys state with a red dot and no text.\n- When an error occurs, the message appears visually but is not announced.\n\nour SDK ships these controls to every customer, so whatever we do here lands everywhere", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "partner integration spec that we have to implement on our side:\n\nPOST /v1/webhooks/tax-filing\n they call us when a filing is accepted or rejected by the tax authority\n headers: X-Filing-Signature (HMAC-SHA512 over the raw body with a shared secret, hex, lowercase)\n body: { filing_id, period, status: \"accepted\"|\"rejected\"|\"partially_accepted\", messages: [{code, severity, text}], received_at }\n we must respond 200 within 5 seconds; they retry for 72 hours with exponential backoff\n a rejected filing must move the period back to open and notify the finance team\n partially_accepted means some documents were rejected; those ids come in messages with severity=error\n duplicate deliveries are expected and must be idempotent on filing_id + status\n their sandbox signs with a different secret and sends `X-Filing-Environment: sandbox`", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for stream credentials, now it needs building:\n\nCREATE TABLE stream_keys (\n id uuid PRIMARY KEY,\n tenant_id uuid NOT NULL,\n stream_id uuid NOT NULL REFERENCES streams(id) ON DELETE CASCADE,\n key_hash bytea NOT NULL,\n prefix text NOT NULL,\n created_at timestamptz NOT NULL DEFAULT now(),\n expires_at timestamptz,\n revoked_at timestamptz,\n last_used_at timestamptz,\n UNIQUE (stream_id, prefix)\n);\n\nkeys are shown once at creation, validated on every ingest request (about 400/s at peak), rotate without interrupting an in-flight stream, and the ingest path must not do a database round trip per segment", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "crf back to 21 in prod", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "zod bump before store review", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "drop the windows leg from CI", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "`buffer_aware_abr` is false in player-config", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "remove the `cookies` permission from the manifest", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "GetHashCode missing on Money", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "proxy_cache_lock on the playlist location", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "das Sync-Intervall der Extension auf 60s", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "de"}
{"prompt": "unawaited task in PostingService", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "waveform under the trim bar", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "focus outlines are removed globally", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "cancelled invoices need a watermark", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "popup is blank when the fetch fails", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "a short decision note about why we're keeping the DVR window in S3 rather than memory", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "our stream key validation is described in the design doc as a constant-time comparison against a hash, and i'd like that verified rather than believed, along with what the ingest path does when the cache is cold and whether a revoked key can still be used by an in-flight session for some window", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "the dunning schedule is 3, 7 and 14 days in the code and 3, 7 and 10 on the customer-facing pricing page, and support has been quoting whichever they saw last. work out which one finance actually agreed, change the other, and check whether any in-flight dunning runs would shift as a result", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "清晰度切换的菜单太窄了", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "zh"}
{"prompt": "seek bar can't be used with a keyboard", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "trim handles don't snap on touch", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "`Manager.Stop` shouldn't hold the mutex", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "pull the VAT maths out of the controller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "`levelSwitching` naming across the SDK", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "InvoiceBuilder everywhere in the tests", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "inline the one-line `RateFor` wrapper", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "split the packager's session watcher", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "release notes for player SDK 4.3", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota interna sobre el cierre de periodo", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "es"}
{"prompt": "document what `X-Discontinuity` does", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the DVR design for the team", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "PR description for the ABR change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "welche Berechtigungen braucht die Extension wirklich?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "de"}
{"prompt": "can the uploader retry a consumed pipe?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the dunning schedule", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "credit notes are a cent off", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "clips upload twice after a worker restart", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "la revalorización nocturna no postea CHF", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "es"}
{"prompt": "signed playback URLs, one hour expiry", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "scope the multi-CDN work, then start on selection", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "map the legacy billing exit, then take the first slice", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "carry on from friday", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "crisper", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "vague-eval", "lang": "en"}
{"prompt": "make it not embarrassing", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "weiter mit dem Player", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "de"}
{"prompt": "sort the extension out", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "do what makes sense here", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick this back up please", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "月末のあれ、進めておいて", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "ja"}
{"prompt": "rest of the ticket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "start on the next bit", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "packager rewrite is half finished and stalled on whether playlists live in redis, which nobody wants to decide because it makes redis a hard dependency on the live path. lay out the options properly — stateless with redis, sharded by stream id with consistent hashing, or leaving it as it is and scaling vertically — with what each costs us operationally at three thousand concurrent streams rather than three hundred", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "finance wants us off the legacy billing service by december and it still owns recurring invoicing, dunning, revenue recognition, the tax export and the PDF generator, plus two hundred stored procedures of which maybe forty are live. i need a sequenced exit plan that keeps invoicing running every month it's being migrated, with an honest view of what we should refuse to port and simply rebuild instead", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "CDN contract renews in october and the cost model changes per gigabyte, which makes the multi-CDN question urgent rather than theoretical. i'd like to understand what per-session CDN selection would require of us — token differences between providers, cache warming doubling origin egress, and the fact that our QoE numbers currently come from one provider's logs — before we negotiate anything", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "extension, our player SDK and our web app all reimplement session handling because they were written by different people in different years, and the sign-in loop bug exists in two of them. before touching any code i want a view on whether these should share a package, what that package would own, and whether the browser constraints make it impossible in practice", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "close process takes finance four to six days and the wiki page describing it is three years out of date, which means new joiners learn it by shadowing someone in a bad mood. write the current process properly, in order, with who does what, and flag clearly the two steps that are broken processes rather than missing documentation", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we're deprecating v3 of the ingest API on the first of october and the current notice is four sentences that tell customers nothing actionable. write the replacement: what changes concretely, what a migrating customer has to do, why the date is firm, and a separate shorter email for the twelve customers who account for most of the traffic", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "transcode ladder and encoder settings differ between staging and production because of a rush change last year, which is probably why we get quality complaints that we can never reproduce internally. before changing anything, read both configs and the ladder logic and tell me what each difference actually does to output quality and cost", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "ADR proposing a stateless packager argues that sharding by stream id is \"operationally complex\" and moves on, which feels like the interesting option being waved away. read the ADR against the code and tell me whether its consequences section is honest, particularly about rendering playlists on every request instead of once per segment", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "VAT rounding helper defaults to half-up on the raw product, and credit notes pass a negative net through it, which the German rules we're being assessed against apparently handle differently. i want to understand exactly what the current code does with negative amounts before we decide whether the audit finding is right", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "packager's session manager holds one mutex across creation, teardown and metrics, and Stop waits for goroutines while holding it, which is why one slow upload stalls every other stream on the instance. decompose it so the lifecycle, the muxing and the uploading are separable, with the same externally observable behaviour and no new races", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "currency conversion exists five times across our services with four different rounding behaviours, and only the billing one has been signed off by the auditors. consolidate onto that behaviour, update every caller, and where a service's numbers will change as a result, list exactly which reports are affected so finance hears it from us first", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "invoices controller does validation, mapping, tax calculation, persistence and email in one method, and the tax part is the bit that's actually subtle. pull it apart without changing the API contract or the emails anyone receives, and make the tax calculation testable on its own because that's where the audit findings keep landing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "internal console, the customer portal and the extension popup each have their own copy of the clip list rendering, and they've drifted enough that the same clip shows three different durations. work out which one is right, unify them behind a shared component, and keep each surface's styling as it is today", "purpose": "refactor", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "playback stalls for about four percent of sessions on one edge, that edge reports perfect availability, and our own telemetry shows the player dropping two levels and still timing out. i don't know whether to look at the CDN, the ABR logic or our segment sizes, and i'd like someone to work through it properly rather than guess", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "month-end didn't tie out by three fifty, and the difference traces to a rounding line that appears once in the subledger and twice in the general ledger, from two system journals posted two seconds either side of midnight. work out how that duplicate arises before we adjust anything, because finance will ask whether it's happened before", "purpose": "debugging", "secondary": "review", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "QoE dashboard has a hardcoded rebuffer threshold, four tiles with no comparison to the previous period, and a breakdown table that can't be sorted, which is why the SRE team still uses a spreadsheet. bring it up to the spec they wrote, and make the threshold configurable per environment rather than baked into the bundle", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "before we build multi-CDN i want the selection strategy designed — how a session picks an edge, how we shift traffic during an incident, how QoE is measured consistently across providers — and then the selection service itself stood up behind a flag so we can shadow it against real traffic", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "ledger project needs breaking up and i'd rather agree the module boundaries with you first, then have you actually move the first module — posting, probably — so we can see whether the boundary survives contact with the build", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "les règles de cache du CDN sont incohérentes entre le direct et le VOD, et l'origine en souffre. j'aimerais d'abord une vraie stratégie de cache écrite noir sur blanc, puis la mise à jour de la configuration en conséquence", "purpose": "planning", "secondary": "quickFix", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "fr"}
{"prompt": "tax filing webhook needs building and there are decisions in it we haven't made — what a rejected filing does to a closed period, who gets notified, whether partially accepted reopens anything. decide those with me, write them down, then implement the handler", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "support answers the same six extension questions every week from a slack thread that scrolls away. write the troubleshooting page properly, and while you're in it, give the popup an actual error state instead of rendering blank when the clip list fails", "purpose": "writing", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "live-stream runbook lives in one engineer's memory and a slack thread. write it as a proper page, and confirm from the code whether `lumenctl session restart` really is safe mid-event or whether that's folklore", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la documentación del nuevo modelo de facturación recurrente para los clientes, y comprueba en el código si el prorrateo se calcula realmente por días naturales como decimos", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "es"}
{"prompt": "player SDK has three subscription styles that have to keep working, and only one of them returns an unsubscribe function. unify the internals behind one mechanism, then document which style we recommend and what the others do differently", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "test project builds invoices three different ways and only the builder computes VAT like production does. move everything onto the builder, then write the short note on test data conventions so the next person doesn't add a fourth", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "deadlock in the posting service happens twice a week and everyone has a theory. i want an actual diagnosis from the deadlock graph and the code, and then the ordering fixed so it can't recur", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": ".NET solution has three projects that all define a `Money` type, and the conversions between them are implicit", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "extension's storage layer mixes chrome.storage.local, sync and an indexeddb wrapper with no rule about which goes where", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "rename the `Trip`-era types in the packager, they date from before we called them streams", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "config is read from appsettings, environment variables and a database table, with different precedence per service", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "SDK exports 40 symbols from its index and most of them are internal helpers nobody should import", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "i'd like to understand how period locking actually prevents postings, because system journals seem to ignore it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "someone should look at whether our ABR change can get stuck at a low level once it drops, given it only steps one at a time", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "why does the extension's service worker restart mid-sync, and is our alarm interval the reason", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain what our cache key configuration does with the Authorization header on the catch-all rule", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that our playlist requests bypass the upstream cache entirely, or has someone misread the nginx config", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "what does the packager actually do when redis is slow — does it queue, drop, or block the live path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "docs/ingest.md still documents the 30 second segment limit that we lowered to 10 in v4", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "内部向けに、配信の障害対応フローを一枚にまとめてほしい", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "ja"}
{"prompt": "xml docs on the posting service describe atomicity guarantees that the code doesn't provide", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "write the store listing description for the extension, the current one is a feature list nobody reads", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "health check on the packager returns healthy while every session is wedged, which is how the outage lasted an hour", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "dunning emails go out at 3, 7 and 14 days in code but the customer-facing page says 3, 7 and 10", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "segment upload retries have no jitter, so a CDN blip produces a perfectly synchronised retry storm", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "发票导出的 CSV 用的是逗号分隔，德国客户打开全是乱的，能不能按区域设置切换", "purpose": "quickFix", "secondary": "backendImpl", "mixed": true, "difficulty": 0.4, "slice": "mixed", "lang": "zh"}
{"prompt": "live edge drifts about two seconds later every hour on long streams, and restarting the session resets it", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "one customer's invoices occasionally get two numbers, and it correlates with them clicking post twice quickly", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "how should we structure the SDK's public surface now that we support three subscription styles and can't break any of them", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "what's the right approach to storing tax rates that change by jurisdiction and date, given we currently hardcode a table", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "an endpoint that returns the DVR window's start and end for a live stream, cheap enough for the player to poll", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "period locking needs to apply to system journals too, with an explicit override that records who used it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a job that expires stream keys that haven't been used in ninety days, with a warning email a week before", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "ingest path should validate stream keys from a cache rather than the database on every segment", "purpose": "backendImpl", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "clip uploads need resumable support, because the extension's worker dies every thirty seconds of idle", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "anything that stops the pager going off", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "doc, finish it off", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "quality menu is too narrow", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "invoice list renders every row's tax breakdown eagerly, which on a month with four thousand invoices means the page takes eight seconds to become interactive and finance has started exporting to excel instead. virtualise the table, keep the column layout and the sticky totals row exactly as they are, and make sure the print stylesheet still produces the full list", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "player's controls fail almost every item in a customer's accessibility audit — no accessible name on the play toggle, a seek bar that's a div with mouse handlers, a volume slider with no role, and focus outlines removed globally in our stylesheet. this ships to every customer, so fix it properly and tell me which parts of the design will visibly change", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "nobody can tell me what happens to a live session when the packager loses its redis connection for ten seconds — whether playlists go stale, the muxer blocks, or viewers see an error — and the code paths for it are spread across three files. work through it and give me the actual behaviour, including what the viewer experiences at each stage", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "stream keys are in the ingest request path, which means they land in access logs, referrer headers and any proxy in between, and security noticed this morning. move them to a header for v4, keep the path form working until october's deprecation, and scrub the existing logs' retention as far as we're able", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "the changelog for the ingest API has no entry for the stream key moving from the path to a header, which is the most disruptive change we've made in two years. write it, plus the migration note explaining what a client has to change and how to tell whether they're still on the old form", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "we need the ingest path to validate stream keys without a database round trip per segment, which at four hundred segments a second is currently a meaningful share of our database load. cache the validated keys with a sensible invalidation on revoke, and make sure a revoked key stops working within seconds rather than whenever the cache happens to expire", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our tax rate table is hardcoded per country in a static class, which was fine when we sold in three countries and is now the reason every rate change is a deploy. i'd like the approach agreed first — effective-dated rows, jurisdiction hierarchy, where the source of truth lives — and then the schema and loader built", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt":"Corrige le timeout de EquinoxBasilRunnerService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"fr"}
{"prompt":"// projects/equinox/cmd/exporter/main.py\nfinal class EquinoxDriftConsoleFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate EquinoxDriftConsoleFlow'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":"Ticket OPS-45111: retire the legacy replay path for EquinoxNimbusFormFlow\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 EquinoxNimbusFormFlow 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":"A copied hex color in EquinoxAcornWidgetStore lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up EquinoxCinderAuthCoordinator. First, assess ownership and failure handling in projects/equinox/workers/thumbnail/consumer.ex. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/equinox/workers/thumbnail/consumer.ex, which follows PostgreSQL 17 conventions and currently suffers from timestamps rendered one day ahead near UTC midnight. Preserve cancellation and back-pressure semantics.\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.7,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-45115\n\n08:02 deploy EquinoxCinderAuthFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current EquinoxCinderAuthFlow 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: # projects/equinox/pkg/cache/lease.rs\n[worker.equinoxravensessionflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.equinoxravensessionflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.equinoxravensessionflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.EquinoxRavenSessionFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-45112\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/equinox/pkg/cache/lease.rs. 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":"EquinoxCedarPolicyCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Does EquinoxWrenExportStore 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.4,"slice":"core","lang":"en"}
{"prompt":"EquinoxBeaconStoreCoordinator: polish the last piece","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Question: Incident timeline — INC-45119\n\n08:02 deploy EquinoxBasilRunnerFlow 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 EquinoxBasilRunnerFlow 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.4,"slice":"pasted-context","lang":"en"}
{"prompt":"Design handed over a final pass for EquinoxCinderAuthStore, and the basic data flow in projects/equinox/workers/thumbnail/consumer.ex already works. 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- preserve cancellation and back-pressure semantics\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to EquinoxCinderAuthStore and its direct tests\n\nSeveral teams work in this identity, Rust CLI, Vue 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 flaky failure around EquinoxMoonlitSDKService survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxMoonlitSDKService\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Em projects/equinox/workers/thumbnail/consumer.ex, o EquinoxCoralUploadStore tem um problema intermitente no fluxo de PostgreSQL 17. Separe responsabilidades e remova duplicação sem mudar API, wire values, ordem ou comportamento observável.\n\nRestrições:\n- continuar com PostgreSQL 17\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao EquinoxCoralUploadStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"Please resist widening this one: EquinoxCraneWorkspaceService works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxCraneWorkspaceService\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Observation: Two deliverables are holding up EquinoxRavenSessionCoordinator. First, assess ownership and failure handling in projects/equinox/crates/index/src/segment.rs. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/equinox/crates/index/src/segment.rs, which follows WebGPU conventions and currently suffers from an empty state that flashes before cached data arrives. Preserve cancellation and back-pressure semantics.\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.7,"slice":"mixed","lang":"en"}
{"prompt":"EquinoxNovaPickerFlow 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.4,"slice":"core","lang":"en"}
{"prompt":"On compact widths, EquinoxSlateEditorService'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":"Ticket OPS-45130: retire the legacy replay path for EquinoxAtlasSearchFlow\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 EquinoxAtlasSearchFlow 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":"Extract EquinoxIrisBatchService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Check EquinoxEmberRelayStore's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"projects/equinox/infra/modules/edge/main.tf now contains EquinoxPrismCacheFlow's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Constraint: Ticket OPS-45144: retire the legacy replay path for EquinoxPineMetricsFlow\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 EquinoxPineMetricsFlow, 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":"Pin EquinoxDriftConsoleService's SQLite dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"EquinoxFernSnapshotCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"EquinoxEchoRegistryStore leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"Compare the old and new EquinoxCedarPolicyService adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter EquinoxJuniperCLIFlow\n RUN v3.2.4 /workspace/apps/console\n × EquinoxJuniperCLIFlow > 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=45143 phase=resume storedCursor=seg-0183\n session=45143 phase=fetch requestCursor=seg-0183 pageSize=200\n session=45143 phase=commit receivedCursor=seg-0184 itemCount=0\n session=45143 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\nDetermine why EquinoxJuniperCLIFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ownership of EquinoxPrismCacheService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current NATS JetStream operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"EquinoxAcornWidgetCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"EquinoxWillowCodecCoordinator: document, then correct","purpose":"writing","secondary":"debugging","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Request: projects/equinox/services/ledger/replay.go の EquinoxCraneWorkspaceFlow で、NATS JetStream の flow に断続的な問題が起きています。 consumer 向けに contract、error、retry、コピー可能な例を含む文書を書き、handler は変更しないでください。\n\n制約:\n- NATS JetStream を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は EquinoxCraneWorkspaceFlow のみ","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"ja"}
{"prompt":"Goal: A flaky failure around EquinoxBirchMigratorStore survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxBirchMigratorStore\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Symptom: // projects/equinox/ml/pipeline/features.py\nfinal class EquinoxFlintTimelineFlowCoordinator {\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Restructure EquinoxFlintTimelineFlow 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":"EquinoxRainfallDBService's staging timeout is already known to be wrong: change the single projects/equinox/infra/modules/edge/main.tf value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Milestones for replacing EquinoxSpruceDaemonService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"EquinoxMapleQueueCoordinator needs a paired pass: lay out a staged migration for EquinoxMapleQueueCoordinator, plus also add the visible loading and offline states. Use projects/equinox/db/migrations/20260730_events.sql as the source of truth, preserve the Tokio contract, and avoid unrelated cleanup.","purpose":"planning","secondary":"frontendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Headsup: // projects/equinox/db/migrations/20260730_events.sql\nfinal class EquinoxNovaPickerCoordinatorCoordinator {\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 EquinoxNovaPickerCoordinator; 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":"Incident timeline — INC-45121\n\n08:02 deploy EquinoxWillowCodecFlow 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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Find the source of this EquinoxWillowCodecFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Before we approve EquinoxBeaconStoreStore, assess whether lost focus when the drawer animation finishes is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"EquinoxDriftConsoleCoordinator: correct, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"FYI: // projects/equinox/src/sync/reconcile.ts\nfinal class EquinoxMapleQueueFlowCoordinator {\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 EquinoxMapleQueueFlow; 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":"The behavior of EquinoxGarnetModalService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/equinox/app/src/main/SyncWorker.kt. 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- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current Tokio operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"EquinoxSlateEditorCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'EquinoxTideWorkerCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[EquinoxTideWorkerCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/equinox/pkg/cache/lease.rs:144: error: -[EquinoxTideWorkerCoordinatorTests 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 '-[EquinoxTideWorkerCoordinatorTests 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\nFinish the visible EquinoxTideWorkerCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Document EquinoxCinderAuthService's cancellation rules","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Two asks around EquinoxAmberFilterCoordinator: (1) finish EquinoxAmberFilterCoordinator's responsive empty and retry states; (2) capture the contract and rollback note for consumers. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/equinox/infra/modules/edge/main.tf b/projects/equinox/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/equinox/infra/modules/edge/main.tf\n+++ b/projects/equinox/infra/modules/edge/main.tf\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 EquinoxRainfallDBFlow 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":"Meanwhile: Two engineers disagree about whether EquinoxHarborIndexStore's cache is authoritative. Walk the reads and writes in projects/equinox/packages/api/openapi.yaml and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"EquinoxQuartzPlayerCoordinator: ship a sensible version","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Locally: // projects/equinox/web/components/FilterDrawer.vue\nfinal class EquinoxCraneWorkspaceCoordinatorCoordinator {\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 EquinoxCraneWorkspaceCoordinator 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":"EquinoxPineMetricsCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Document EquinoxMosaicGridStore's cancellation rules","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Rename EquinoxSummitProxyStore's staleLease state","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"EquinoxNimbusFormCoordinator is blocking the next release because out-of-order events after consumer rebalancing. I need two concrete outcomes from a single pass: finish EquinoxNimbusFormCoordinator's responsive empty and retry states, and capture the contract and rollback note for consumers. Use the existing NATS JetStream conventions in projects/equinox/services/ledger/replay.go; preserve cancellation and back-pressure semantics. 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":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"EquinoxAcornWidgetService'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":"Architect a gradual ownership transfer for EquinoxOpalRouterFlow across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Collapse the EquinoxBirchMigratorService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"# projects/equinox/internal/auth/refresh.go\n[worker.equinoxlumenchartflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.equinoxlumenchartflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.equinoxlumenchartflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.EquinoxLumenChartFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-45116\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/equinox/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":"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_45140'\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_45140'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDetermine why EquinoxSlateEditorFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-45136: retire the legacy replay path for EquinoxWrenExportFlow\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 EquinoxWrenExportFlow 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":"Set EquinoxMapleQueueStore's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Production: Ticket OPS-45128: retire the legacy replay path for EquinoxSummitProxyFlow\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 EquinoxSummitProxyFlow 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":"Production says EquinoxRavenSessionService is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. 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- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current WebGPU operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Move EquinoxGarnetModalFlow's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Security flagged EquinoxLumenChartStore for a read-only pass because its NATS JetStream boundary mixes tenant data, retries, and cancellation in subtle ways. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current NATS JetStream operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"For EquinoxKiteSchedulerCoordinator, assess ownership and failure handling in projects/equinox/ui/settings/PrivacyPane.tsx; once that is complete, capture the contract and rollback note for consumers. Work from projects/equinox/ui/settings/PrivacyPane.tsx, stay with PostgreSQL 17, and preserve cancellation and back-pressure semantics. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"The next client release depends on a new EquinoxGarnetModalStore capability in projects/equinox/apps/console/routes/usage.svelte, with Tokio already chosen by the platform group. Wire the schema, repository, handler, and worker so duplicate deliveries return the original result and shutdown never acknowledges uncommitted work.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing Tokio deployment\n- keep the work scoped to EquinoxGarnetModalStore and its direct tests\n\nSeveral teams work in this identity, Rust CLI, Vue monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Two asks around EquinoxMosaicGridCoordinator: (1) produce a consumer guide for EquinoxMosaicGridCoordinator; (2) give the existing implementation a read-only safety pass. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Pin EquinoxWillowCodecStore's NATS dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Staging: // projects/equinox/packages/api/openapi.yaml\nfinal class EquinoxSableParserCoordinatorCoordinator {\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 EquinoxSableParserCoordinator; 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":"CI: The API work is done; what remains for EquinoxSableParserService is the visible interaction layer across loading, offline, empty, and success cases. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxSableParserService\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Set EquinoxAmberFilterStore's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"PM is preparing the EquinoxDeltaCanvasStore rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxDeltaCanvasStore\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"# projects/equinox/pkg/cache/lease.rs\n[worker.equinoxamberfilterflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.equinoxamberfilterflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.equinoxamberfilterflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.EquinoxAmberFilterFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-45132\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 EquinoxAmberFilterFlow'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":"Please resist widening this one: EquinoxNovaPickerService works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxNovaPickerService\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"In projects/equinox/web/components/FilterDrawer.vue hat EquinoxNimbusFormService ein sporadisches Problem im NATS JetStream-Ablauf. Die Ursache ist klar: Ändere nur das Staging-Timeout von 15 auf 30 Sekunden und passe die Assertion an.\n\nRandbedingungen:\n- NATS JetStream weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf EquinoxNimbusFormService begrenzen","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"de"}
{"prompt":"Atlas: The public surface of EquinoxFlintTimelineService is frozen, but its internal ownership in projects/equinox/ml/pipeline/features.py is difficult to test and even harder to change safely. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxFlintTimelineService\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-45129: finish the compact EquinoxMosaicGridFlow filter experience\n\nRoute: /catalog/search\nSource: projects/equinox/app/src/main/SyncWorker.kt\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\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Use the UI evidence to complete EquinoxMosaicGridFlow'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":"thread 'tokio-runtime-worker' panicked at projects/equinox/apps/console/routes/usage.svelte:217:18:\ncalled `Result::unwrap()` on an `Err` value: SendError { .. }\n\nstack backtrace:\n 0: std::panicking::begin_panic_handler\n 1: core::panicking::panic_fmt\n 2: core::result::unwrap_failed\n 3: equinoxgarnetmodalcoordinator::scheduler::LeaseTask::flush\n at ./projects/equinox/apps/console/routes/usage.svelte:217:18\n 4: equinoxgarnetmodalcoordinator::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 EquinoxGarnetModalCoordinator 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":"Match EquinoxEchoRegistryService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Bring EquinoxFrostPanelService'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":"Could EquinoxSlateEditorStore show the active PostgreSQL 17 sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Why is EquinoxSummitProxyService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"EquinoxAtlasSearchStore leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Ownership of EquinoxMoonlitSDKStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current PostgreSQL 17 operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.\n\nReturn the restructuring sequence and decision points, not the edits themselves.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-45150: retire the legacy replay path for EquinoxCloudReconcilerCoordinator\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 EquinoxCloudReconcilerCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Decouple EquinoxMapleQueueService's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/equinox/internal/auth/refresh.go b/projects/equinox/internal/auth/refresh.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/equinox/internal/auth/refresh.go\n+++ b/projects/equinox/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 EquinoxPrismCacheCoordinator's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"A previously stable test around EquinoxNovaPickerStore now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"A previously stable test around EquinoxWrenExportService now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"EquinoxLumenChartCoordinator: diagnose, then correct","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Beacon: Ticket OPS-45134: retire the legacy replay path for EquinoxBeaconStoreFlow\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 EquinoxBeaconStoreFlow 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":"How does EquinoxCedarPolicyStore propagate cancellation through the PostgreSQL 17 boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Is EquinoxEmberRelayService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"For EquinoxIrisBatchCoordinator, ship the idempotent EquinoxIrisBatchCoordinator replay endpoint; once that is complete, correct the known stale timeout beside it. Work from projects/equinox/services/ledger/replay.go, stay with NATS JetStream, and preserve cancellation and back-pressure semantics. Keep the two outcomes separately reviewable.","purpose":"backendImpl","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Could the reasoning behind EquinoxRainfallDBStore's NATS JetStream choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/equinox/Sources/App/SessionStore.swift b/projects/equinox/Sources/App/SessionStore.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/equinox/Sources/App/SessionStore.swift\n+++ b/projects/equinox/Sources/App/SessionStore.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 EquinoxSpruceDaemonFlow 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":"Split EquinoxWillowCodecService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current EquinoxMicaProfileStore design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside EquinoxMicaProfileStore\n- preserve cancellation and back-pressure semantics\n\nThis repository spans identity, Rust CLI, Vue; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"EquinoxCoralUploadCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Rename EquinoxMicaProfileService's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"Unifie les validateurs de EquinoxMarbleTokenStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"fr"}
{"prompt":"EquinoxOrbitSyncCoordinator needs a paired pass: find the unknown cause of lease renewal code copied across three workers, plus give the existing implementation a read-only safety pass. Use projects/equinox/cmd/exporter/main.py as the source of truth, preserve the SQLite contract, and avoid unrelated cleanup.","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"The name pendingAck means two different things across EquinoxLedgerGateService's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"EquinoxBasilRunnerCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Skizziere die EquinoxBasilRunnerStore-Migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"What is the safest way to split projects/equinox/app/src/main/SyncWorker.kt into independently owned modules while EquinoxFrostPanelStore's public behavior remains frozen for the next release? Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Cinder: Ticket OPS-45153: retire the legacy replay path for EquinoxOpalRouterCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Assess EquinoxOpalRouterCoordinator 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":"EquinoxMicaProfileCoordinator is blocking the next release because lost focus when the drawer animation finishes. I need two concrete outcomes from a single pass: lay out a staged migration for EquinoxMicaProfileCoordinator, and consolidate the duplicated normalization paths without changing behavior. Use the existing Tokio conventions in projects/equinox/src/sync/reconcile.ts; preserve cancellation and back-pressure semantics. 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":"planning","secondary":"refactor","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"We need to move EquinoxBeaconStoreService from the legacy store to Tokio. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"// projects/equinox/config/staging.toml\nfinal class EquinoxMarbleTokenFlowCoordinator {\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 EquinoxMarbleTokenFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Delta: A copied hex color in EquinoxOspreyJobFlow lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-45114\n\n08:02 deploy EquinoxMicaProfileFlow 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\nReconstruct the EquinoxMicaProfileFlow 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":"Ember: A copied hex color in EquinoxSableParserStore lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'EquinoxQuartzPlayerFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[EquinoxQuartzPlayerFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/equinox/Sources/App/SessionStore.swift:144: error: -[EquinoxQuartzPlayerFlowTests 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 '-[EquinoxQuartzPlayerFlowTests 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 EquinoxQuartzPlayerFlow'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":"EquinoxWrenExportCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-45135: retire the legacy replay path for EquinoxCoralUploadFlow\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 EquinoxCoralUploadFlow 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":"Center the EquinoxSpruceDaemonStore modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"Frost: diff --git a/projects/equinox/packages/api/openapi.yaml b/projects/equinox/packages/api/openapi.yaml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/equinox/packages/api/openapi.yaml\n+++ b/projects/equinox/packages/api/openapi.yaml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Read the artifact above as a skeptical reviewer. Is EquinoxAcornWidgetFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"EquinoxFrostPanelCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"EquinoxQuartzPlayerService 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":"Garnet: projects/equinox/db/migrations/20260730_events.sql now contains EquinoxPineMetricsStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Harbor: projects/equinox/crates/index/src/segment.rs has grown through several launches, and EquinoxTideWorkerService now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing WebGPU deployment\n- keep the work scoped to EquinoxTideWorkerService and its direct tests\n\nSeveral teams work in this identity, Rust CLI, Vue 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":"Does EquinoxPrismCacheStore 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":"Spell EquinoxKiteSchedulerStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"EquinoxJuniperCLICoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_45148'\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_45148'::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\nAdd the bounded EquinoxCopperBridgeFlow 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":"Add a bounded EquinoxCloudReconcilerStore 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":"Since the last release, EquinoxOspreyJobService has shown timestamps rendered one day ahead near UTC midnight; nobody on the team can reproduce it reliably on a laptop. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to EquinoxOspreyJobService and its direct tests\n\nSeveral teams work in this identity, Rust CLI, Vue monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a EquinoxCopperBridgeStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"En projects/equinox/cmd/exporter/main.py, EquinoxOpalRouterService tiene un problema intermitente en el flujo de SQLite. Termina el layout responsive, estados vacío y retry, foco por teclado, dark mode y reduced motion.\n\nRestricciones:\n- seguir con SQLite\n- conservar compatibilidad y cancelación\n- limitar el cambio a EquinoxOpalRouterService","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"es"}
{"prompt":"Give EquinoxOspreyJobStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"The next client release depends on a new EquinoxRavenSessionStore capability in projects/equinox/crates/index/src/segment.rs, with WebGPU already chosen by the platform group. Wire the schema, repository, handler, and worker so duplicate deliveries return the original result and shutdown never acknowledges uncommitted work.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing WebGPU deployment\n- keep the work scoped to EquinoxRavenSessionStore and its direct tests\n\nSeveral teams work in this identity, Rust CLI, Vue monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Support wants the behavior in projects/equinox/web/components/FilterDrawer.vue recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Test Suite 'EquinoxEmberRelayFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[EquinoxEmberRelayFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/equinox/lib/codec/frame.cc:144: error: -[EquinoxEmberRelayFlowTests 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 '-[EquinoxEmberRelayFlowTests 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 EquinoxEmberRelayFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Iris: Test Suite 'EquinoxEchoRegistryFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[EquinoxEchoRegistryFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/equinox/crates/index/src/segment.rs:144: error: -[EquinoxEchoRegistryFlowTests 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 '-[EquinoxEchoRegistryFlowTests 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\nFinish the visible EquinoxEchoRegistryFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Design the EquinoxOrbitSyncService rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"EquinoxEmberRelayCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"# projects/equinox/services/ledger/replay.go\n[worker.equinoxfernsnapshotflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.equinoxfernsnapshotflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.equinoxfernsnapshotflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.EquinoxFernSnapshotFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-45141\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 EquinoxFernSnapshotFlow'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":"Could the reasoning behind EquinoxDeltaCanvasFlow's SQLite choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Flip EquinoxLumenChartService's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Ownership of EquinoxFlintTimelineStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current SQLite operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.\n\nReturn the restructuring sequence and decision points, not the edits themselves.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Add a bounded EquinoxLedgerGateStore export stream that resumes from checkpoints, respects cancellation, and exposes queue lag plus terminal failure counters.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Polish the EquinoxVelaDrawerService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"How does EquinoxFernSnapshotService propagate cancellation through the NATS JetStream boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Collapse the EquinoxIrisBatchStore wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"We expect EquinoxDeltaCanvasService to outgrow its current SQLite arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing SQLite deployment\n- keep the work scoped to EquinoxDeltaCanvasService and its direct tests\n\nSeveral teams work in this identity, Rust CLI, Vue monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Juniper: # projects/equinox/crates/index/src/segment.rs\n[worker.equinoxledgergateflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.equinoxledgergateflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.equinoxledgergateflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.EquinoxLedgerGateFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-45142\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/equinox/crates/index/src/segment.rs. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Kestrel: We need to move EquinoxTideWorkerStore from the legacy store to WebGPU. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for EquinoxOrbitSyncStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-45149\n\n08:02 deploy EquinoxAsterWebhookFlow 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 EquinoxAsterWebhookFlow 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":"EquinoxMarbleTokenCoordinator needs a paired pass: produce a consumer guide for EquinoxMarbleTokenCoordinator, plus correct the known stale timeout beside it. Use projects/equinox/packages/api/openapi.yaml as the source of truth, preserve the WebGPU contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Lumen: Incident timeline — INC-45155\n\n08:02 deploy EquinoxOspreyJobCoordinator 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 EquinoxOspreyJobCoordinator 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":"Wire a EquinoxOpalRouterStore background task in projects/equinox/ml/pipeline/features.py that expires abandoned sessions, records an OpenTelemetry span, and yields cleanly when shutdown begins.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Read projects/equinox/lib/codec/frame.cc and tell me whether EquinoxCloudReconcilerFlow 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":"EquinoxAtlasSearchCoordinator needs a paired pass: separate EquinoxAtlasSearchCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/equinox/lib/codec/frame.cc as the source of truth, preserve the PostgreSQL 17 contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Maple: Incident timeline — INC-45133\n\n08:02 deploy EquinoxOrbitSyncFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the EquinoxOrbitSyncFlow 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":"EquinoxRainfallDBCoordinator: give it a nicer flow","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Nimbus: projects/equinox/cmd/exporter/main.py の EquinoxJuniperCLIService で、SQLite の flow に断続的な問題が起きています。 原因は判明済みです。staging timeout だけを 15 秒から 30 秒へ変え、対応する assertion を直してください。\n\n制約:\n- SQLite を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は EquinoxJuniperCLIService のみ","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"ja"}
{"prompt":"UI ticket DES-45139: finish the compact EquinoxFrostPanelFlow filter experience\n\nRoute: /catalog/search\nSource: projects/equinox/apps/console/routes/usage.svelte\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\nBring EquinoxFrostPanelFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"For EquinoxSummitProxyCoordinator, separate EquinoxSummitProxyCoordinator's policy from transport without behavior changes; once that is complete, capture the contract and rollback note for consumers. Work from projects/equinox/Sources/App/SessionStore.swift, stay with SQLite, and preserve cancellation and back-pressure semantics. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"EquinoxHarborIndexCoordinator: handle the lingering thing","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/equinox/Sources/App/SessionStore.swift b/projects/equinox/Sources/App/SessionStore.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/equinox/Sources/App/SessionStore.swift\n+++ b/projects/equinox/Sources/App/SessionStore.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\nRead the artifact above as a skeptical reviewer. Is EquinoxDeltaCanvasCoordinator's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"EquinoxAsterWebhookCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"// projects/equinox/web/components/FilterDrawer.vue\nfinal class EquinoxIrisBatchFlowCoordinator {\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 EquinoxIrisBatchFlow 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":"How should EquinoxAtlasSearchService be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for EquinoxMoonlitSDKCoordinator:\n- primary outcome: lay out a staged migration for EquinoxMoonlitSDKCoordinator\n- companion outcome: then implement the bounded durable-cursor handler\n- repository entry point: projects/equinox/lib/codec/frame.cc\n- platform constraint: PostgreSQL 17\n- known complication: a deadlock that appears only during shutdown\n\nBoth results are required, but they should remain independently reviewable. Preserve cancellation and back-pressure semantics; 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":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Fresh release brief for EquinoxFlintTimelineCoordinator:\n- primary outcome: assess ownership and failure handling in projects/equinox/cmd/exporter/main.py\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/equinox/cmd/exporter/main.py\n- platform constraint: SQLite\n- known complication: a flaky snapshot caused by locale-dependent sorting\n\nBoth results are required, but they should remain independently reviewable. Preserve cancellation and back-pressure semantics; 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":"EquinoxBirchMigratorCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"EquinoxCopperBridgeCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"On compact widths, EquinoxQuartzPlayerStore's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Memory attributed to EquinoxPineMetricsService 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":"Could the reasoning behind EquinoxTideWorkerFlow's WebGPU choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"EquinoxSpruceDaemonCoordinator: document, then correct","purpose":"writing","secondary":"backendImpl","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-45117: retire the legacy replay path for EquinoxBirchMigratorFlow\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 EquinoxBirchMigratorFlow 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":"EquinoxEchoRegistryCoordinator: sequence, then ship","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/equinox/infra/modules/edge/main.tf b/projects/equinox/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/equinox/infra/modules/edge/main.tf\n+++ b/projects/equinox/infra/modules/edge/main.tf\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 EquinoxVelaDrawerFlow'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 EquinoxCloudReconcilerService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/equinox/lib/codec/frame.cc. 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- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current PostgreSQL 17 operational envelope\n\nThe relevant code crosses identity, Rust CLI, Vue. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Ticket OPS-45110: retire the legacy replay path for EquinoxMoonlitSDKFlow\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 EquinoxMoonlitSDKFlow 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":"Compare the old and new EquinoxAsterWebhookStore 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":"En projects/equinox/services/ledger/replay.go, EquinoxNimbusFormStore tiene un problema intermitente en el flujo de NATS JetStream. Propón fases, compatibilidad, métricas, rollback y ownership; detente antes de tocar código.\n\nRestricciones:\n- seguir con NATS JetStream\n- conservar compatibilidad y cancelación\n- limitar el cambio a EquinoxNimbusFormStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con NATS JetStream alrededor de EquinoxNimbusFormStore.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"Sketch the EquinoxVelaDrawerStore migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Bring EquinoxCraneWorkspaceStore'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":"EquinoxAsterWebhookService returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/equinox/app/src/main/SyncWorker.kt and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The EquinoxCopperBridgeService 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":"Sequence EquinoxMosaicGridService's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-45147\n\n08:02 deploy EquinoxHarborIndexFlow 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 EquinoxHarborIndexFlow, 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":"EquinoxLedgerGateCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Flip EquinoxAmberFilterService's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Make EquinoxDriftConsoleStore keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"projects/equinox/ml/pipeline/features.py 里的 EquinoxJuniperCLIStore 最近在 SQLite 流程中出现间歇性问题。 请实现幂等 endpoint，包含持久 cursor、tenant 鉴权、spans 和 retry 测试。\n\n约束：\n- 继续使用 SQLite\n- 保持兼容性和取消语义\n- 改动只限于 EquinoxJuniperCLIStore","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"zh"}
{"prompt":"Documente o contrato de EquinoxMarbleTokenService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"Opal: projects/equinox/ui/settings/PrivacyPane.tsx 里的 EquinoxCoralUploadService 最近在 PostgreSQL 17 流程中出现间歇性问题。 请阅读现有流程，判断 ownership、取消和顺序是否安全，只需要分析。\n\n约束：\n- 继续使用 PostgreSQL 17\n- 保持兼容性和取消语义\n- 改动只限于 EquinoxCoralUploadService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"zh"}
{"prompt":"Remove EquinoxKiteSchedulerService's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Two asks around EquinoxVelaDrawerCoordinator: (1) separate EquinoxVelaDrawerCoordinator's policy from transport without behavior changes; (2) correct the known stale timeout beside it. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Prism: The EquinoxHarborIndexService surface in projects/equinox/config/staging.toml 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":"Quartz: // projects/equinox/workers/thumbnail/consumer.ex\nfinal class EquinoxKiteSchedulerFlowCoordinator {\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\nDeliver the EquinoxKiteSchedulerFlow 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":"Raven: Incident timeline — INC-45145\n\n08:02 deploy EquinoxCedarPolicyFlow 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，并明确说明证据和取舍。 Map a safe route from the current EquinoxCedarPolicyFlow 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":"How does EquinoxSableParserFlow propagate cancellation through the WebGPU boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
data/round2-06.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "payroll run 2026-07 blew up halfway through and left 400 employees unpaid:\n\norg.springframework.dao.DeadlockLoserDataAccessException: PreparedStatementCallback; SQL [update payslip set net_cents=?, status=? where id=?]; Deadlock found when trying to get lock; try restarting transaction\n\tat org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:263)\n\tat io.paycrest.payroll.PayslipRepository.updateNet(PayslipRepository.java:141)\n\tat io.paycrest.payroll.RunProcessor.processEmployee(RunProcessor.java:212)\n\tat io.paycrest.payroll.RunProcessor.lambda$run$3(RunProcessor.java:88)\n\tat java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)\nCaused by: java.sql.SQLTransactionRollbackException: Deadlock found when trying to get lock\n\nrun 88412, 1,204 employees, parallel stream over the employee list, 8 threads", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer falls behind head every few hours and never catches up without a restart:\n\n2026-07-29T11:02:14Z INFO indexer: processing block 21,104,882 (lag 2 blocks)\n2026-07-29T11:04:02Z INFO indexer: processing block 21,104,918 (lag 41 blocks)\n2026-07-29T11:08:11Z WARN indexer: rpc request took 8.4s method=eth_getLogs range=1000\n2026-07-29T11:08:19Z WARN indexer: rpc request took 11.2s method=eth_getLogs range=1000\n2026-07-29T11:12:44Z WARN indexer: reorg detected at 21,104,801, rolling back 12 blocks\n2026-07-29T11:12:58Z INFO indexer: reprocessing from 21,104,789 (lag 214 blocks)\n2026-07-29T11:31:02Z WARN indexer: postgres connection pool exhausted (20/20), waiting\n2026-07-29T11:44:18Z INFO indexer: processing block 21,104,912 (lag 604 blocks)\n\nthe RPC provider says our request rate is well within limits", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "our safety concept document has to go to the auditor in november, and writing it will expose where our latency budget doesn't close. produce the document, and give me a separate honest list of the numbers that don't add up so we can decide what to fix first", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "the payroll module ignores half our design tokens and its warning colour fails contrast on the row background it's used with. bring it onto the tokens, fix the contrast, and note in the design system docs which token pairs are safe on which surfaces there are fourteen hardcoded colours in there, six of them near-misses of a real token.", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "angular app throws this on the timesheet screen for about one user in fifty:\n\nERROR RangeError: Maximum call stack size exceeded\n at Object.eval [as updateDirectives] (TimesheetGridComponent.html:41:9)\n at Module.debugUpdateDirectives (core.mjs:44112:12)\n at checkAndUpdateView (core.mjs:41882:5)\n at callViewAction (core.mjs:42214:21)\nERROR Error: NG0100: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value for 'ngClass': 'row-warning'. Current value: 'row-error'.\n at throwErrorIfNoChangesMode (core.mjs:12044:11)\n\nthe grid has a getter in the template that computes the row state from the entries, and users with more than about 200 entries in a week hit it", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer pool size up to 40", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "payroll thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "our angular app pulls fontawesome and moment into the initial bundle for three date formats and four icons, which is most of the budget overrun. replace both, keep the rendering identical, and check the print stylesheet still works", "purpose": "quickFix", "secondary": "refactor", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt": "the payroll run has no alert when it sits in RUNNING for more than an hour, which is how we found out at breakfast", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "robot stops mid-path maybe once a day, and this is what the diagnostics dump:\n\nros2 topic hz /scan\n average rate: 9.412 min: 0.104s max: 0.882s std dev: 0.14112s window: 50\nros2 topic hz /odom\n average rate: 49.881 min: 0.019s max: 0.021s std dev: 0.00041s window: 50\n\n[nav2_controller]: Control loop missed its desired rate of 20.0000Hz... the loop actually took 0.2841 seconds\n[nav2_controller]: Invalid path, Path is empty.\n[behavior_server]: Running backup\n[bt_navigator]: Behavior tree threw exception: Action server timed out\n\nthe lidar is meant to publish at 10Hz and the CPU on the nav box sits at 60%", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "payslip PDF still says 2025 tax year", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "a spanish customer signs in september and we support four countries, none of them spain, which means social security bands, a different absence model and a filing format we've never produced. before anyone opens the calculator i want a plan: what a country pack actually has to contain, how much of spain is data versus code, and whether we can get there without touching the other four countries' behaviour at all", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "we owe a customer a written explanation for why four hundred people were paid late, and their HR director's actual question is why we didn't know until the morning. write the incident report: what happened, what the impact was, why our monitoring missed it, and what changes — without hiding behind the word \"deadlock\"", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "angular component behind our slowest screen. is the getter the whole problem or just part of it?\n\n@Component({\n selector: 'timesheet-grid',\n template: `\n <tr *ngFor=\"let row of rows\" [ngClass]=\"rowState(row)\">\n <td *ngFor=\"let day of row.days\">{{ formatHours(day) }}</td>\n <td>{{ totalFor(row) }}</td>\n </tr>`\n})\nexport class TimesheetGridComponent {\n @Input() entries: Entry[] = []\n get rows() { return this.groupByEmployee(this.entries) }\n rowState(r: Row) { return r.days.some(d => this.hasConflict(d)) ? 'row-error' : 'row-warning' }\n totalFor(r: Row) { return r.days.reduce((a, d) => a + this.minutes(d), 0) / 60 }\n hasConflict(d: Day) { return this.entries.filter(e => e.day === d.date).length > 1 }\n}", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "before this goes anywhere near a payroll run, tell me what's wrong with it:\n\n@Transactional\npublic void run(UUID runId) {\n PayrollRun run = runs.findById(runId).orElseThrow();\n run.getEmployees().parallelStream().forEach(emp -> {\n Payslip slip = calculator.calculate(emp, run.getPeriod());\n payslips.save(slip);\n run.addTotal(slip.getNetCents());\n });\n run.setStatus(COMPLETED);\n runs.save(run);\n events.publish(new PayrollCompleted(runId, run.getTotalCents()));\n}\n\nrun.addTotal mutates a long field on the entity; calculator hits the database for tax bands per employee", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "three services in the ROS graph each do their own transform lookup, with their own error handling:\n\n// pick_place_node.cpp\ntry { tf_buffer_->lookupTransform(\"base_link\", \"tool0\", tf2::TimePointZero); }\ncatch (const tf2::TransformException& e) { RCLCPP_WARN(get_logger(), \"%s\", e.what()); return; }\n\n// perception_node.cpp\nauto tf = tf_buffer_->lookupTransform(\"base_link\", \"camera_link\", msg->header.stamp,\n tf2::durationFromSec(0.1)); // throws on timeout\n\n// safety_node.cpp\nif (!tf_buffer_->canTransform(\"base_link\", \"lidar\", tf2::TimePointZero)) { return last_known_; }\n\none returns stale data on failure, one drops the message, one throws into a callback", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "absence type dropdown is missing bereavement", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "one date-range validator for all controllers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "what happens when a tax table is missing?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "is `IsSafe` thread-safe as written?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "robot cell has to pass certification in november and our own numbers don't obviously add up — the perception pipeline alone measures 180ms against a 250ms budget, and the safety check shares a process with the motion controller. work through what the architecture would need to look like to actually satisfy the requirement, and what evidence we'd have to produce alongside it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "payslip generation, PDF rendering and the bank file writer all live in one class called `PayrollService`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a walkthrough of how an absence becomes a deduction line would help before i touch the calculator", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "we need bank file generation to be resumable, because a 40MB export currently regenerates from scratch on every poll", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "arm drifts a few centimetres over a shift and we recalibrate every morning as a workaround:\n\n[ INFO] [1753843201.114]: joint_state_publisher: publishing at 50Hz\n[ WARN] [1753843261.882]: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 1753843261.880\n[ WARN] [1753843262.114]: TF_REPEATED_DATA ignoring data with redundant timestamp for frame tool0 at time 1753843262.112\n[ WARN] [1753843321.441]: Lookup would require extrapolation into the past. Requested time 1753843321.401 but the earliest data is at time 1753843321.412\n[ERROR] [1753843382.002]: Trajectory execution aborted: goal tolerance violated on joint_4 (0.0142 > 0.0100)\n[ INFO] [1753843382.114]: controller reset, resuming\n\nsim is perfect, and it only happens on the two cells with the newer controllers", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "webhooks to our customers' HR systems started failing on tuesday, only for two of them:\n\nPOST https://hr.customer-a.example/webhooks/paycrest\n → 200 OK in 412ms\n\nPOST https://api.customer-b.example/paycrest\n → SSL routines:ssl3_read_bytes:sslv3 alert handshake failure\n → retry 1: same\n → retry 2: same\n → giving up after 3 attempts, event queued\n\nPOST https://hooks.customer-c.example/in\n → 421 Misdirected Request\n → retry 1: 421\n → giving up\n\nwe upgraded the base image on monday, from debian bookworm to trixie", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "reorg handling, which i inherited and don't trust:\n\nasync fn handle_block(&mut self, block: Block) -> Result<()> {\n let parent = self.db.get_block(block.number - 1).await?;\n if parent.hash != block.parent_hash {\n let depth = self.find_common_ancestor(&block).await?;\n self.db.delete_blocks_from(depth + 1).await?;\n self.cursor = depth;\n return Ok(());\n }\n let logs = self.rpc.get_logs(block.number, block.number).await?;\n let mut tx = self.db.begin().await?;\n self.db.insert_block(&mut tx, &block).await?;\n for log in logs { self.apply_log(&mut tx, log).await?; }\n tx.commit().await?;\n self.cursor = block.number;\n Ok(())\n}\n\nfind_common_ancestor walks back one block at a time; delete_blocks_from cascades to the balances table", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "this is the safety check on our motion controller and i want another pair of eyes before the certification audit:\n\nbool MotionController::IsSafe(const State& s) const {\n if (estop_pressed_.load()) return false;\n if (s.velocity.norm() > max_velocity_) return false;\n if (last_heartbeat_age() > std::chrono::milliseconds(250)) return false;\n for (const auto& obstacle : obstacles_) {\n if ((s.position - obstacle.position).norm() < safety_radius_) return false;\n }\n return true;\n}\n\nobstacles_ is refreshed by the perception callback on another thread; last_heartbeat_age reads a member updated in the same callback; there is no mutex anywhere in this class", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "RFC for our new payout scheduling. does the reasoning survive contact with reality?\n\n## Proposal\nMove payroll runs from a single nightly batch to a queue of per-employee jobs. Each job is independently retryable, and a run completes when every job reports success.\n\n## Rationale\nA single failing employee currently fails the whole run, and we cannot restart from the middle.\n\n## Consequences\n- Partial runs become visible to customers, who will ask what \"partially paid\" means.\n- Totals can no longer be computed in the same transaction as the slips.\n- Retry storms are possible if the tax service is down.\n\n## Open\nWhether a run can be approved before all jobs complete.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "safety documentation for the cell, which the auditor will read line by line. what we have:\n\n- e-stop cuts power to the servo drives directly, software is not in the loop\n- the software safety check runs at 100Hz and stops motion if the heartbeat is older than 250ms\n- obstacle detection comes from two lidars, fused, with a 200mm safety radius around the tool\n- reduced-speed mode is entered when a human is detected in the cell, at 250mm/s\n- the perception pipeline has a measured worst-case latency of 180ms\n- recovery from a safety stop requires a physical reset, not a software command\n\nwrite the safety concept document; where our numbers don't add up against a 250ms budget, say so rather than smoothing it over", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the indexer, from the commits since v0.9:\n\n41c9e0b feat(reorg): handle reorgs deeper than 12 blocks\n88f21c0 fix(logs): decode indexed value parameters on Transfer\nc0aa774 perf(rpc): batch eth_getLogs into 200-block ranges\n2e91b45 fix(db): don't hold a transaction across an RPC call\naa30f19 feat(api): expose /v1/balances/{address} with block-height parameter\n9c1d004 chore: bump alloy to 0.8\n4410bb7 fix(cursor): persist the cursor after commit, not before\nb77e910 feat(metrics): per-contract indexing lag\n\nour users are other teams who run this themselves; two of these change behaviour in ways that need explaining", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "support keeps getting asked this and answering differently each time. from the code, write the definitive page:\n\ncustomer question: \"When exactly does an absence affect pay? We entered sick leave on the 28th for the period that closed on the 25th, and the employee was paid in full, then a correction appeared the following month with no explanation on the payslip.\"\n\nwhat the code does: absences in a closed period are accepted with retro=true; the next run generates a correction line; the correction line's description is the absence type only, with no dates; the payslip PDF renders corrections in a separate block at the bottom; and if the employee leaves before the next run, the correction is silently dropped", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "same date-range validation lives in four controllers with four different error messages:\n\n// AbsenceController\nif (req.getEnd().isBefore(req.getStart())) throw new BadRequest(\"end before start\");\n\n// TimesheetController\nif (!req.getEnd().isAfter(req.getStart())) throw new BadRequest(\"invalid range\");\n\n// ReportController\nif (req.getStart().plusYears(1).isBefore(req.getEnd())) throw new BadRequest(\"range too wide\");\nif (req.getEnd().isBefore(req.getStart())) throw new BadRequest(\"end before start\");\n\n// PayrollController\nAssert.isTrue(req.getStart().compareTo(req.getEnd()) <= 0, \"bad range\");\n\nthe API contract says a range where start equals end is valid, and two of these disagree", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer's event decoding is a match arm per contract and there are now 40 of them:\n\nmatch (log.address, log.topics[0]) {\n (addr, topic) if addr == USDC && topic == TRANSFER => decode_transfer_indexed(log),\n (addr, topic) if addr == DAI && topic == TRANSFER => decode_transfer(log),\n (addr, topic) if addr == WETH && topic == TRANSFER => decode_transfer(log),\n (addr, topic) if addr == USDC && topic == APPROVAL => decode_approval(log),\n // ... 36 more\n _ => Ok(None),\n}\n\nadding a token means editing this match, and half the arms differ only in whether the value parameter is indexed", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the timesheet week view, angular, replacing the grid that falls over:\n\nWeek view (desktop, 1280px+)\n- Employee rows, sticky first column with name and role, 7 day columns plus a total column.\n- Cells show hours as a decimal to one place; empty cells show an em dash at 40% opacity.\n- Conflicts (two entries on the same day) render an amber left border on the cell and a tooltip listing both.\n- Cells are editable inline: click focuses an input, enter commits and moves down, escape reverts, tab moves right.\n- Unsaved edits show a small dot in the corner; a failed save turns the cell's border destructive with a retry affordance.\n- The total column recalculates optimistically as you type.\n- Above 500 rows the table virtualises, but the sticky column and the totals must stay correct while scrolling.\n- Keyboard-only operation must be possible for the whole grid, including conflict resolution.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "run progress bar needs an elapsed timer", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "why does startup take four minutes?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "whatever the auditor needs", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "timesheet screen is the top support complaint and the obvious fix is virtualising the grid, but i suspect the real problem is that the component recomputes everything in template getters. before committing to a rewrite i want a view on whether this is a restructure of the existing component or a genuine redesign, and what each would cost", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether our motion controller's safety check is actually safe, because the obstacle list and the heartbeat are written by a perception callback on another thread and there isn't a mutex in the class. read it properly and tell me what can go wrong, how likely it is, and whether the certification auditor would accept it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "employee portal fails most of an accessibility audit and our public sector customers will ask about it at renewal. fix the concrete items — the payslip iframe, the calendar keyboard navigation, form error association — and write the accessibility statement we can publish afterwards the statement has to be specific enough that a procurement reviewer can check it.", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "i want a position on whether the robot's perception and safety should share a computer at all", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "one tf lookup helper for the three nodes", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "three more chains are on the indexer's roadmap and each one is a week of work plus permanent RPC cost, while the existing chain already falls behind after every reorg. i'd rather we agreed what \"supporting a chain\" means for us — backfill, lag SLOs, cost per chain — before saying yes to any of them, and then decided which of the three is actually worth doing first", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "before we build spanish payroll i want the country-pack boundary agreed — what's data, what's code, how tax years are versioned — and then the boundary proven by moving one existing country onto it, ideally the simplest one, so we find out what's wrong with the design before spain lands", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "is the reporting query's correlated subquery the reason it times out, or is it the left join on payslips", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does the export endpoint make when two of the customer's servers poll it at once", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "absence approval endpoint should reject approvals from someone in the requester's own reporting line", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "les cotisations sociales sont fausses pour trois salariés et je ne vois pas pourquoi :\n\nSalarié 4412 brut 3 200,00 plafond SS 3 864,00 tranche A 3 200,00 tranche B 0,00 ✓\nSalarié 4418 brut 4 100,00 plafond SS 3 864,00 tranche A 3 864,00 tranche B 236,00 ✓\nSalarié 4421 brut 4 100,00 plafond SS 3 864,00 tranche A 4 100,00 tranche B 0,00 ✗\nSalarié 4429 brut 5 000,00 plafond SS 3 864,00 tranche A 3 864,00 tranche B 1 136,00 ✓\nSalarié 4433 brut 4 100,00 plafond SS 3 864,00 tranche A 4 100,00 tranche B 0,00 ✗\n\nles trois salariés en erreur ont tous eu un avenant au contrat en cours de mois, et le plafond devrait être proratisé", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "fr"}
{"prompt": "balances in the indexer disagree with the chain for exactly four addresses:\n\naddress indexed on-chain diff\n0x8f21c0aa774119a2b3c4d5e6f7a8b9c0d1e2f3a4 1,204.118401 1,204.118401 0\n0x41ba190c0aa7741192b3c4d5e6f7a8b9c0d1e2f3 882.441000 882.437600 0.0034\n0x2e91b45aa30f199c1d0044410bb7b77e91030cc2 0.000000 12.400000 12.4\n0xc0aa7741ba190882e91b452e91b45aa30f199c1d 4,118.220000 4,118.220000 0\n0xaa30f199c1d0044410bb7b77e91030cc219e1f0a 41.000000 40.999999 0.000001\n\nreconciliation job output:\n checked 41,882 addresses across 12 tokens\n mismatches: 4 (all on token 0x9c1d0044410bb7b77e91030cc219e1f0a8f21c0a)\n first divergence at block 21,041,882\n last full agreement at block 21,041,881\n\nthe token's ABI:\n event Transfer(address indexed from, address indexed to, uint256 indexed value)\n\nevery other token we index declares value as a non-indexed parameter, and all four addresses received from this contract", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "payroll engine migration has two months of parallel running left and has to finish before year end, but the diff process is a gist, the sign-off is an email, and nobody has defined what a clean month looks like. i'd like the remaining migration planned properly, including the cutover criteria, what we do if month four fails, and how we prove to an auditor afterwards that the numbers matched", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "indexer decodes events through a forty-arm match on address and topic, where most arms differ only in whether the value parameter is indexed, and adding a token means editing it. replace it with a registry that's data rather than code, keeping the decoding behaviour byte-identical for every contract we currently index", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "our javadoc claims the run is atomic, which stopped being true when we parallelised it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "the payroll run has no alert while it sits in RUNNING, which is why a failure at two in the morning was found at six by a human. add the alerting, and tell me what else in that pipeline has the same shape — a state that can be entered and never left without anyone noticing", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "angular build warnings that have been ignored for a year and now break the budget:\n\nWarning: bundle initial exceeded maximum budget. Budget 1.00 MB was not met by 412.11 kB with a total of 1.40 MB.\nWarning: src/app/timesheet/timesheet-grid.component.ts depends on 'moment'. CommonJS or AMD dependencies can cause optimization bailouts.\nWarning: src/app/shared/icons.ts depends on '@fortawesome/fontawesome-free'. CommonJS or AMD dependencies can cause optimization bailouts.\nWarning: src/app/payroll/payroll.module.ts is part of the declarations of 2 modules\n\nError: Budget exceeded, build failed\n\nmoment is used in three files for date formatting only", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer needs a story for backfilling a single contract after a decoding bug, without reindexing everything or touching other contracts' data. think it through with me — cursor per contract, ranges, how balances get recomputed — then implement the range-reprocessing command ranges have to be resumable, because one contract's history is months of blocks.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "payroll calculator is one class with a branch per country, two hundred lines each, and the proposal on the table is a rules engine with country packs loaded at runtime. i can see why, and i can also see auditors asking which rules produced a payslip three years ago. weigh the options honestly, including the boring one where it stays code but gets restructured", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "our health endpoint reports the indexer healthy while it's six hundred blocks behind head", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "the `dual_write` flag governs the whole payroll migration and nobody can say precisely what it switches any more. work out what it actually does from the code, then write the page describing it, including what happens if someone turns it off halfway through a run", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "robot cell repo has a two-line readme and a twenty-minute manual calibration procedure documented in a scanned pdf. write the readme a new engineer could actually follow to a moving robot, including the vendored driver patch, the realtime kernel requirement, and the launch-order problem that bites everyone on hardware assume the reader has used ROS before but has never seen this cell.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "payslip viewer should let people download the PDF without opening the iframe at all", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "a short note for the team on why balances are becoming a sum over deltas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "we need to decide whether the timesheet week view keeps its own state or moves to the store the rest of the app uses", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "angular modules call the API three different ways depending on which year they were written, three components forget to unsubscribe, and only one handles the error case. bring all fourteen onto the newest pattern, keep every screen behaving as it does now, and make the error handling consistent rather than absent fourteen components in total, and the newest pattern is the one we want to end up on.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "spring boot app takes 4 minutes to start in prod and 20 seconds locally:\n\n2026-07-29T11:02:14.881Z INFO 1 --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)\n2026-07-29T11:02:18.114Z INFO 1 --- [main] o.h.jpa.internal.util.LogHelper : HHH000204: Processing PersistenceUnitInfo [name: default]\n2026-07-29T11:04:41.882Z INFO 1 --- [main] o.h.e.j.e.i.LobCreatorBuilderImpl : HHH000424: Disabling contextual LOB creation as createClob() method threw error\n2026-07-29T11:05:52.114Z INFO 1 --- [main] o.s.o.j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'\n2026-07-29T11:06:02.441Z INFO 1 --- [main] i.p.config.TaxTableLoader : loaded 41,882 tax bands\n2026-07-29T11:06:14.002Z INFO 1 --- [main] i.paycrest.Application : Started Application in 241.118 seconds\n\nthe gap between 11:02:18 and 11:04:41 is where it sits doing nothing visible", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "gazebo sim passes, real robot fails the same test, and the only difference i can find is timing:\n\n[component_container]: Failed to load component: Package 'gripper_driver' not found\n[component_container]: Component loaded: force_sensor_node\n[force_sensor_node]: Publishing /wrench at 500Hz\n[gripper_action_server]: Waiting for /wrench...\n[gripper_action_server]: Waiting for /wrench...\n[gripper_action_server]: Timed out waiting for /wrench after 5.0s\n[pick_place_node]: Aborting: gripper action server unavailable\n[pick_place_node]: Retrying (1/3)\n[gripper_action_server]: Received first /wrench message\n\nthe force sensor node comes up about 6 seconds after the gripper server on hardware, instantly in sim", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "der Kollege hat das für die Lohnabrechnung geschrieben, bitte einmal drüberschauen:\n\npublic BigDecimal berechneSteuer(BigDecimal brutto, Steuerklasse klasse, int jahr) {\n var tabelle = tabellen.get(jahr);\n if (tabelle == null) {\n tabelle = tabellen.get(jahr - 1); // Fallback auf das Vorjahr\n }\n var band = tabelle.stream()\n .filter(b -> brutto.compareTo(b.von()) >= 0 && brutto.compareTo(b.bis()) <= 0)\n .findFirst()\n .orElse(tabelle.get(tabelle.size() - 1));\n return brutto.multiply(band.satz()).setScale(2, RoundingMode.HALF_UP);\n}\n\ndie Tabellen für 2026 sind noch nicht eingepflegt, und die Klasse wird nirgends verwendet", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "sql the reporting screen runs, which times out for our biggest customer:\n\nSELECT e.id, e.full_name, d.name AS department,\n SUM(p.gross_cents) AS ytd_gross,\n SUM(p.tax_cents) AS ytd_tax,\n (SELECT COUNT(*) FROM absences a WHERE a.employee_id = e.id AND a.starts_at >= $2) AS absence_count,\n (SELECT MAX(pr.paid_at) FROM payslips pr WHERE pr.employee_id = e.id) AS last_paid\nFROM employees e\nJOIN departments d ON d.id = e.department_id\nLEFT JOIN payslips p ON p.employee_id = e.id AND p.period >= $2\nWHERE e.org_id = $1 AND e.terminated_at IS NULL\nGROUP BY e.id, e.full_name, d.name\nORDER BY e.full_name;\n\n41,000 employees, payslips has 4.1M rows, and there's an index on payslips(employee_id, period)", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "ROS launch file, which nobody wants to touch. what does it actually guarantee about startup order?\n\ndef generate_launch_description():\n return LaunchDescription([\n Node(package='lidar_driver', executable='lidar_node', output='screen'),\n Node(package='force_sensor', executable='force_node', output='screen'),\n Node(package='gripper_driver', executable='gripper_action_server', output='screen'),\n TimerAction(period=5.0, actions=[\n Node(package='nav2_bringup', executable='navigation_launch', output='screen'),\n ]),\n Node(package='pick_place', executable='pick_place_node', output='screen',\n parameters=[{'wrench_timeout': 5.0}]),\n ])\n\non hardware the force sensor takes about six seconds to enumerate over USB", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "payroll's parallel-run notes from the migration, they need to become a proper runbook:\n\n- we run the old and new engines on the same period and diff the payslips\n- differences under 2 cents are ignored, anything above goes in a spreadsheet\n- the diff script lives in a gist, takes a run id, and needs read access to both databases\n- known acceptable differences: rounding on pension contributions, and the order of deduction lines\n- if more than 5 employees differ we don't cut over that month\n- the finance lead signs off by replying to an email, which is our only record\n- we've done this for three months and have two months to go", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "public API for absences, documented by nobody. this is what the controller does:\n\n@PostMapping(\"/v2/absences\")\npublic AbsenceDto create(@RequestBody @Valid AbsenceRequest req, @AuthenticationPrincipal Principal p) {\n // employee must belong to the caller's org, else 404 (deliberately not 403)\n // overlapping absences of the same type are rejected with 409\n // overlapping absences of different types are allowed and both count\n // half days are expressed as 0.5 in `days`, quarter days are not supported\n // absences in a closed payroll period are accepted but flagged `retro: true`\n // a retro absence triggers a correction on the next run, never a rerun\n // the `approver_id` is ignored on create and set by the approval endpoint\n}\n\nwrite the reference page, and be explicit about the 404-instead-of-403 because integrators keep filing bugs about it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from the failed payroll run, and 400 people were paid late. we owe the customer a write-up:\n\n02:14 run 88412 starts, 1,204 employees\n02:31 run fails with a database deadlock, status stuck at RUNNING\n02:33 automatic retry starts, fails identically\n06:02 on-call notices during the morning check, not from an alert\n06:40 we establish 804 payslips were written and 400 were not\n07:15 decision: complete the run manually rather than restart it\n09:52 remaining 400 payslips generated, bank file submitted\n11:30 bank confirms the second file, employees paid same day but late\n14:00 root cause: parallel processing of employees updating a shared run total row\n\nthe customer's HR director wants to know why we didn't know until the morning", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "escribe la guía de despliegue a partir de estas notas, que hoy están en la cabeza de una persona:\n\n- el indexador se despliega con helm, pero antes hay que parar el reorg handler manualmente\n- si no se para, la migración de la tabla `blocks` se bloquea y hay que matar la conexión a mano\n- las migraciones se aplican con `sqlx migrate run` desde un pod temporal, no en el arranque\n- después del despliegue hay que verificar que el cursor avanza; si no avanza en dos minutos, rollback\n- el rollback es volver al chart anterior y reiniciar desde el último checkpoint, se pierden unos 10 minutos de datos\n- nunca desplegar durante una reorganización en curso, se corrompen los saldos\n- hay un feature flag `dual_write` que debe estar activo durante toda la migración", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "es"}
{"prompt": "README for the robot cell repo, currently two lines. what a new person needs:\n\n- ROS 2 Jazzy, ubuntu 24.04, colcon workspace, three packages plus a vendored driver\n- the vendored gripper driver has a patch on top of upstream that must be reapplied after any update, patch is in patches/\n- simulation: `ros2 launch cell_bringup sim.launch.py`, works on any machine\n- hardware: needs the realtime kernel, the user in the dialout group, and the safety PLC in maintenance mode\n- the calibration procedure is a 20 minute manual process documented in a pdf someone scanned\n- tests: unit tests run anywhere, integration tests need either sim or hardware and are not in CI\n- known issue: the force sensor enumerates slowly on hardware, which breaks the launch order\n\nwrite the readme so someone can get to a moving robot without a tap on the shoulder", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "o texto do email que vai para 1.400 empregados está mau, reescreve-o:\n\n\"Caro colaborador, Informamos que devido a uma incidência técnica no processamento do vencimento referente ao mês de Julho, o pagamento poderá ter sido efetuado com atraso relativamente à data habitual. A situação encontra-se resolvida. Agradecemos a compreensão. Departamento de Recursos Humanos.\"\n\nfactos: o pagamento chegou no mesmo dia mas várias horas mais tarde; não houve erro nos valores; ninguém precisa de fazer nada; quem tenha tido encargos bancários por causa do atraso deve contactar o RH e será reembolsado", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "pt"}
{"prompt": "checkstyle and spotbugs after the merge, and the build gate goes on next week:\n\n[ERROR] PayslipRepository.java:141: Method length is 88 lines (max allowed is 50). [MethodLength]\n[ERROR] RunProcessor.java:88: 'if' construct must use '{}'s. [NeedBraces]\n[WARNING] TaxTableLoader.java:22: Found reliance on default encoding: new FileReader(String) [DM_DEFAULT_ENCODING]\n[WARNING] AbsenceService.java:66: Possible null pointer dereference of approver in AbsenceService.approve() [NP_NULL_ON_SOME_PATH]\n[WARNING] Money.java:41: Class defines equals() but not hashCode() [HE_EQUALS_USE_HASHCODE]\n\n2 errors, 3 warnings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "clippy on the indexer, some of these look like they matter:\n\nwarning: this `.await` holds a non-Send type across an await point\n --> src/indexer/handler.rs:88:9\nwarning: large enum variant\n --> src/types.rs:41:1\n |\n41 | enum Event { Transfer(TransferEvent), Approval(Box<ApprovalEvent>), Raw([u8; 4096]) }\nwarning: this loop never actually loops\n --> src/rpc/retry.rs:22:5\nwarning: called `unwrap` on a `Result` value in an async fn\n --> src/db/cursor.rs:141:32\n\nwarning: `indexer` (bin \"indexer\") generated 18 warnings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "connection pool settings across our services, and the indexer is the one that exhausts:\n\n# api\nspring.datasource.hikari.maximum-pool-size: 40\nspring.datasource.hikari.connection-timeout: 30000\n\n# worker\nspring.datasource.hikari.maximum-pool-size: 20\nspring.datasource.hikari.connection-timeout: 30000\n\n# indexer (rust, sqlx)\nmax_connections: 20\nacquire_timeout: 30s\nidle_timeout: 600s\n\n# postgres\nmax_connections = 100\nreserved_connections = 3\n\nthe indexer opens a transaction per block and holds it across the RPC call for logs", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "docker base image bump broke outbound TLS to two customers, here's the difference:\n\n# before (bookworm)\nopenssl version: OpenSSL 3.0.11\nMinProtocol = TLSv1.2\nCipherString = DEFAULT@SECLEVEL=2\n\n# after (trixie)\nopenssl version: OpenSSL 3.5.0\nMinProtocol = TLSv1.2\nCipherString = DEFAULT@SECLEVEL=3\n\ncustomer-b's endpoint:\n TLSv1.2, ECDHE-RSA-AES128-SHA, RSA 2048, SHA1 signature\ncustomer-c's endpoint:\n TLSv1.2, cipher fine, but the certificate chain is missing an intermediate", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "パラメータの設定が本番とステージングで違っていて、実機だけ止まる原因かもしれません:\n\n# staging (sim) — config/controller.sim.yaml\ncontroller:\n loop_rate: 20.0\n goal_tolerance: 0.02\n lidar_rate_expected: 10.0\n wrench_timeout: 5.0\n tf_buffer_duration: 10.0\n use_sim_time: true\n max_velocity: 0.5\n\n# production (hardware) — config/controller.hw.yaml\ncontroller:\n loop_rate: 20.0\n goal_tolerance: 0.01\n lidar_rate_expected: 10.0\n wrench_timeout: 5.0\n tf_buffer_duration: 1.0\n use_sim_time: false\n max_velocity: 0.5\n\n# 実機のログ（抜粋、1 時間に 40 回ほど）\n[ WARN] Lookup would require extrapolation into the past. Requested time 1753843321.401 but the earliest data is at time 1753843321.412\n[ERROR] Trajectory execution aborted: goal tolerance violated on joint_4 (0.0142 > 0.0100)\n[ INFO] controller reset, resuming\n\ntf_buffer_duration は去年、メモリ使用量を下げるために変更したものです。goal_tolerance を誰が変えたのかは記録が残っていません", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "ja"}
{"prompt": "github action for the rust indexer, cache never hits:\n\n- uses: actions/checkout@v4\n- uses: dtolnay/rust-toolchain@stable\n- uses: actions/cache@v4\n with:\n path: |\n ~/.cargo/registry\n target\n key: ${{ runner.os }}-cargo-${{ github.sha }}\n- run: cargo build --release\n- run: cargo test --all-features\n- run: cargo clippy -- -D warnings\n\nevery run: \"Cache not found for input keys: Linux-cargo-<sha>\"\nbuild time: 14 minutes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "this calculator has grown a parameter every time a country was added. same numbers out, better shape:\n\npublic Payslip calculate(Employee e, Period p, boolean includeBonus, boolean prorate,\n Country country, TaxYear year, boolean applyPensionCap,\n BigDecimal overrideRate, boolean skipSocial, List<Deduction> extra) {\n if (country == Country.FR && prorate) { /* 40 lines */ }\n else if (country == Country.DE) { /* 60 lines, ignores prorate */ }\n else if (country == Country.PT) { /* 30 lines, uses overrideRate if set */ }\n else { /* the original UK path, 80 lines */ }\n}\n\nfour call sites pass different combinations, and two of them pass nulls for parameters the branch ignores", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "unser Angular-Code hat drei Wege, dieselbe API zu rufen. Bitte vereinheitlichen, ohne Verhalten zu ändern:\n\n// altes Modul\nthis.http.get<Absence[]>('/api/v2/absences').subscribe(a => this.absences = a)\n\n// neueres Modul\nthis.absenceService.list().pipe(takeUntilDestroyed()).subscribe(a => this.absences.set(a))\n\n// neuestes Modul\nabsences = toSignal(inject(AbsenceService).list(), { initialValue: [] })\n\nvierzehn Komponenten insgesamt, drei davon vergessen das Abmelden, und der Fehlerfall wird nur in einem behandelt", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "de"}
{"prompt": "test fixtures for payroll are four builders that disagree about defaults:\n\nEmployee e1 = TestEmployees.uk(); // salaried, tax code 1257L, no pension\nEmployee e2 = new EmployeeBuilder().build(); // salaried, no tax code at all\nEmployee e3 = Fixtures.employee(FR); // hourly, with a pension scheme\nEmployee e4 = anEmployee().withSalary(50000).build(); // salaried, UK, pension at 5%\n\nabout 900 tests, and a test that passes with one builder often fails with another because of the pension default", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "planning input for the half, and i need a sequence rather than a wish list:\n\n- payroll engine migration has two months of parallel running left, and it has to finish before year end\n- a customer in Spain signs in september and we don't support Spanish social security at all\n- the timesheet screen is the top support complaint and is unusable above 200 entries\n- the indexer team wants to add three chains, each of which is a week of work plus ongoing RPC cost\n- our robot cell customer needs the certification audit passed by november or the deployment slips a year\n- two engineers are shared between payroll and the indexer and are context-switching badly\n- there's a compliance deadline in january for real-time payroll reporting in one country", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket that needs thinking, not code:\n\nPAY-620 — Multi-country payroll calculation\nThe calculator is one class with a country branch and 200 lines per country. Adding Spain means a fifth branch. Proposal is a rules engine with country packs loaded at runtime, so a country can be added without a deploy. Concerns raised: payroll rules change annually and must be versioned by tax year; auditors need to see exactly which rules produced a given payslip, years later; a rules engine makes the calculation harder to unit test than a plain class; and two of our countries have rules that genuinely need arbitrary code, not data.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "indexer's roadmap request from the teams that depend on it:\n\n- three more chains, with the same API surface\n- historical backfill on demand rather than the current \"reindex everything\" script\n- per-contract lag metrics so a team can alert on their own contract falling behind\n- a way to reprocess a range after a decoding bug, without touching other contracts' data\n- read replicas, because the reporting queries are now competing with indexing writes\n- some story for reorgs deeper than our current 12-block assumption\n\none engineer, one quarter. what would you do and in what order", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "customer requirement for the robot cell, and the certification audit is in november:\n\n\"The safety function shall bring the manipulator to a controlled stop within 250 ms of a human entering the collaborative workspace. Detection shall be redundant, with no single sensor failure defeating the function. The safety function shall be independent of the application software and shall be verifiable without disassembly. Evidence shall include a documented worst-case latency analysis covering sensing, processing, communication and actuation.\"\n\nour perception pipeline alone measures 180ms worst case, the safety check runs in the same process as the motion controller, and we have two lidars but they feed one fusion node", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the payroll run screen, which is what customers stare at on the 25th:\n\nRun detail\n- Header: period, status (Draft / Calculating / Ready / Approved / Paid / Failed), employee count, total net. Status drives a coloured left border on the whole card.\n- Progress: during Calculating, a determinate bar with \"812 of 1,204 payslips\", updating over websocket, plus an elapsed timer.\n- Employee table: name, gross, deductions, net, a warning glyph where the payslip differs from last period by more than 20%.\n- Filters: only warnings, only changes, by department. Filters persist for the session.\n- Approve is a primary button, disabled unless status is Ready, with a confirmation dialog that restates the total and the employee count.\n- Failed state shows which employees failed, why, and a Retry failed button that does not touch the successful ones.\n- Everything must degrade gracefully when the websocket drops — fall back to polling, never show stale progress as live.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility audit of the employee portal, which our public sector customers care about:\n\n- The payslip PDF viewer is an iframe with no title and no text alternative; screen reader users get nothing.\n- The absence calendar is a table of divs; dates are not announced and arrow-key navigation does nothing.\n- Form errors appear only as red text under the field, not associated with the input and not announced.\n- The \"submit timesheet\" flow uses colour alone to indicate which days are incomplete.\n- Focus is lost to the top of the page after every modal closes.\n- Session timeout warning appears visually with a countdown that is never announced.\n- Contrast fails on the secondary button in both themes (3.1:1).", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the payroll module actually uses:\n\ntokens:\n color.text.default #1B1F23\n color.text.muted #5A6672\n color.status.warning #B26A00\n color.status.danger #B3261E\n space.1..6 4 8 12 16 24 32\n radius.sm/md/lg 4 8 12\n font.size.body 14/20\n font.size.caption 12/16\n\npayroll module: 14 hardcoded hex values, six of which are near-misses of the token colours; paddings of 6, 10 and 18px; two font sizes not in the scale; and a warning colour that fails contrast on the row background it's used with\n\nbring it onto the tokens and fix the contrast failure while you're there", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "integration spec our customer's HR system expects from us:\n\nGET /v2/exports/payroll?period=2026-07&format=sepa-xml\n auth: mutual TLS with a client cert we issue, plus an API key header\n response: 200 with the file, or 202 with a Location header if generation takes longer than 5 seconds\n the 202 path must be pollable and the result cached for 24 hours\n the file must be byte-identical on repeated requests for the same period unless a correction was posted\n a correction invalidates the cache and increments a `revision` in the filename\n they poll every 30 seconds from three of their servers, so concurrent identical requests must not generate the file three times\n file sizes are up to 40MB and they cannot handle chunked encoding", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for reorg-safe balances, needs implementing in the indexer:\n\nCREATE TABLE balance_deltas (\n id bigserial PRIMARY KEY,\n address bytea NOT NULL,\n token bytea NOT NULL,\n delta numeric(78,0) NOT NULL,\n block_number bigint NOT NULL,\n log_index int NOT NULL,\n UNIQUE (block_number, log_index)\n);\nCREATE INDEX ON balance_deltas (address, token, block_number);\n\nbalances become a sum over deltas up to a block height; a reorg deletes deltas above the fork point; the /v1/balances endpoint must answer at any height without scanning the whole history, and it's currently answering from a mutable balances table that reorgs corrupt", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "drop moment from the timesheet module", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "cargo cache key uses the sha", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "lower the indexer's batch to 200 blocks", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "la fecha del recibo sale en formato americano", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "es"}
{"prompt": "seclevel back to 2 for the outbound client", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "tf buffer duration to 10s on hardware", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "hashCode missing on the Money class", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "payroll calculator takes ten parameters, four of which are ignored on three of the four country paths, and two call sites pass nulls into branches that never read them. restructure it so each country's rules live somewhere coherent, with identical output for every payslip in the last twelve months as the acceptance criterion the last twelve months of payslips are the regression suite, so nothing may move by a cent.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "indexer holds a database transaction across an RPC call, which is why the pool exhausts whenever the provider is slow", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "our on-call has no alerting on payroll runs at all, and the obvious alerts would have caught tuesday's failure four hours earlier", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "the tax table loader falls back to the previous year when the current year's bands aren't loaded, silently, and the 2026 bands are not in yet. before we change anything i want to know exactly what that fallback produces on a real payslip and how we'd have noticed if a customer hadn't told us", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "das Bundle-Budget auf 1,5 MB anheben", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "de"}
{"prompt": "unwrap in db/cursor.rs, make it fallible", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "warning glyph on payslips that jumped 20%", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "sticky name column on the week view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "empty cells should show an em dash", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "chain selector in the indexer console", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "休暇カレンダーの矢印キー操作が効きません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
{"prompt": "secondary button contrast fails in both themes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "focus jumps to the top after a modal closes", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "conflict border should be amber, not red", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "boundary", "lang": "en"}
{"prompt": "totals row scrolls away", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "`RunProcessor` per-country strategies", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "decode table instead of 40 match arms", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "un seul builder pour les tests de paie", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "fr"}
{"prompt": "`gross_cents` naming, everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "pull the retry policy out of the rpc client", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "inline `minutes()`, one caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "signals everywhere in the absence module", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "javadoc on the payroll calculator, please", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "changelog entry for the reorg fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "kurze Notiz zur Parallelabrechnung", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "de"}
{"prompt": "document the retro absence behaviour", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the safety concept for the auditor", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the balance deltas change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "¿el indexador maneja bien las reorganizaciones?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "can two runs touch the same payslip?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the approval flow", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "payslips missing for 400 employees", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "arm drifts over a shift", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "webhooks to two customers fail TLS", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "warum hängt der Indexer nach einer Reorg?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for per-contract indexing lag", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "algo pequeno para hoje", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "pt"}
{"prompt": "carry on where that left off", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidier, please", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "grid, you know", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "next one on the list", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "same but for Spain", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "unblock the robot people", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "faster, ideally", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "another look at that screen", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "finish the migration bit", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "le truc d'hier, la suite", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "fr"}
{"prompt": "start wherever you like", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "absences API is integrated against by six customers and documented nowhere, which is why we get the same three bugs filed repeatedly — the 404 instead of 403, the retro flag, and half days. write the reference page from the controller's actual behaviour, with the surprising parts called out rather than buried in a table", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "deployment procedure for the indexer lives in one engineer's head and includes at least two steps that will corrupt balances if skipped. write it up as a runbook: the pre-deploy checks, the manual stop, the migration step, how to tell within two minutes whether it worked, and exactly what rollback costs us in lost data", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "support answers \"when does an absence affect pay\" differently every time, and the honest answer involves retro flags, corrections on the next run, and a case where the correction is silently dropped. write the page that settles it, in language an HR administrator understands, and be explicit about the dropped-correction case rather than omitting it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "reorg handler walks back one block at a time to find a common ancestor and deletes forward with a cascade to balances, and i want to understand what that does during a twelve-block reorg while the indexer is already behind. no changes yet — i want to know what actually happens, including what a reader sees mid-rollback", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "RFC proposing per-employee payroll jobs mentions that partial runs become customer-visible and then moves on, which is the part i'd have thought hardest. read it against how runs work today and tell me whether the consequences section is complete, particularly around approval before all jobs finish i would rather know now than after we have built the queue.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "four addresses have balances that disagree with the chain, all of them holding a token whose Transfer event indexes the value parameter, unlike every other token we index. work out whether our decoder is silently producing zero for those, and how many other contracts we index have the same shape i also want to know how many other contracts we index emit the same event shape.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "timesheet grid needs to survive five hundred rows without falling over, which means virtualising it, but the sticky employee column and the optimistic totals have to keep working while scrolling. rebuild it to the spec, keep inline editing and keyboard navigation exactly as designed, and make sure conflicts are still visible when a row is partially scrolled", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "payroll run screen shows progress over a websocket and simply freezes when the socket drops, which during a run is indistinguishable from the run being stuck. add a polling fallback, make stale progress visibly stale rather than silently wrong, and keep the approve button's guard conditions exactly as they are it should also survive the tab being backgrounded for ten minutes and brought back.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "safety architecture needs redesigning for certification and there's a piece we can start regardless: separating the safety check into its own process with its own watchdog. give me the design for the whole thing first, then do that separation so we have something to measure assume the auditor will ask for the latency budget in writing, with measurements.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "unsere Zeiterfassung ist auf Wochenbasis gebaut und ein Kunde braucht Schichtmodelle über Mitternacht hinweg. Ich hätte gern zuerst ein Konzept, wie das Datenmodell aussehen müsste, und danach die Migration der bestehenden Einträge", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "de"}
{"prompt": "real-time payroll reporting becomes a legal requirement in one country in january and we currently report monthly in a batch. map out what compliance means for our architecture, then start on whichever piece has the longest lead time — my guess is the submission client, but tell me if it isn't", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "parallel-run process for the payroll migration exists only as folklore and a gist. write it up properly as a runbook, and while you're in the diff script, make it fail loudly when it can't reach one of the two databases instead of reporting zero differences the finance lead's email sign-off should become something we can actually find later.", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "escreve a documentação da API de exportação para o cliente e confirma no código se o ficheiro é mesmo idêntico entre pedidos repetidos, porque é isso que estamos a prometer", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "pt"}
{"prompt": "three employees got the wrong social security bands and all three had a contract amendment mid-month, which suggests the cap isn't being prorated. confirm that from the code, then fix it and tell me how many past payslips are affected i would also like to know whether mid-month terminations hit the same proration bug.", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "robot stops mid-path about once a day and the lidar's publishing rate is wildly variable in the logs. work out whether that's the sensor, the USB bus or our own callback blocking, and once you know, put the diagnostic in place that would tell us next time without a manual dump", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like to understand what our launch file actually guarantees about node startup order on hardware", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "is it expected that the indexer's cursor is persisted before the commit rather than after", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "docs/payroll.md describes the old sequential run and the retry semantics we removed", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "api changelog needs an entry for the balances endpoint's block-height parameter", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer-facing note about the late payment, apologetic but factual, one paragraph", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "necesitamos documentar qué hace el flag `dual_write` durante la migración, nadie se acuerda", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "es"}
{"prompt": "dates differ between the UI and PDF", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "goal tolerance on hardware is half what it is in sim, and nobody knows who changed it or why", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "per-contract cursors in the indexer, so one slow contract doesn't hold up everything else", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "how should we version country payroll rules so an auditor can reproduce a payslip from three years ago", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test payroll calculations, given that a wrong answer is a legal problem rather than a bug", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "two engineers are split across payroll and the indexer and neither project is moving, what would you do about the allocation", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "what should the story be for customers who want their payroll data in their own warehouse, three have asked now", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "run detail screen needs the failed-employee list with a retry that skips the successful ones", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "absence calendar should show public holidays for the employee's country, greyed and non-selectable", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "indexer console needs a reorg history view, so we can see when balances were rolled back", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "reporting screen times out on our biggest customer and the obvious fix is pagination, which finance will hate", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "whatever is on fire", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "other half of that", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "deduction-line ordering differs between the old and new payroll engines, which the migration diff flags every month and we've been waving through as cosmetic. work out whether the order is actually meaningful for the payslip PDF and the bank file, make the new engine match wherever it is, and then write down what \"acceptable difference\" means so the next person isn't guessing", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "topic names are hardcoded as string literals in forty places across the ROS packages, with two typos that only bite in one launch configuration. centralise them properly, and while you're there tell me whether the two typo'd topics were ever connected to anything or have been silently dead since the port to Jazzy", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "`PayrollService` does payslip generation, PDF rendering and bank file writing in one class of about nine hundred lines, and the bank file part is the bit under audit. split it along those three responsibilities, then document which class owns what so the auditor's questions have an obvious answer", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "our angular error handling is three parsers deep because each spring service invented its own error shape. unify the server side onto one shape, and confirm from the client code which of the three parsers is still reachable before you delete anything", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "employee test fixtures exist in four flavours with different pension defaults, which is why moving a test between packages changes its outcome. consolidate onto one builder, then write the short note on fixture conventions that should have existed before the fourth one appeared about nine hundred tests depend on these, so the migration has to be mechanical.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "i want to know whether a parallel stream over employees can corrupt the run total — the entity has a mutable long that every thread adds to — and if it can, the fix, with a test that reproduces it reliably rather than one that passes by luck the run total is a mutable long on the entity, which is the part that worries me.", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "angular timesheet grid recomputes row state in a template getter on every change detection pass, which i think explains both the stack overflow and the changed-after-checked error. confirm the mechanism from the code, then tell me the smallest change that fixes it without the rewrite we've been putting off", "purpose": "review", "secondary": "planning", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "before i touch the calculator i'd like to understand how an absence becomes a deduction line — which service decides the daily rate, what happens with a half day, and where the retro flag enters — and then have the tax table cache invalidation documented, because i can't find the call at all", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "we need per-contract cursors in the indexer so one slow contract doesn't hold up the rest, but that changes what \"indexed up to block N\" means for the API and for our lag alerts. decide the semantics with me first, then implement the cursor split", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "error responses differ per spring service — some return a problem-details object, some a bare string, one an html error page from the container — and the angular client has grown a parser for each. settle on one shape across the services, keep every status code as it is, and make sure the html case can't happen at all", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "payslip generation, PDF rendering and bank file writing share one class and one set of tests, so a change to the PDF layout requires understanding the bank file format. separate them with the same public entry points, and keep the generated output byte-identical for the last three periods as the acceptance test", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "nobody can tell me how a payslip correction gets matched back to the absence that caused it, which matters because the correction line on the PDF shows only the absence type. trace it through and explain the matching, including what happens when two absences of the same type land in the same closed period", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "leavers keep their portal access until the next payroll run processes their termination, which HR has now raised as a compliance problem rather than an inconvenience. revoke access at the termination date instead, keep payslip access for the statutory period, and make sure a termination entered in error can be reversed without a support ticket", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a nightly job should flag employees whose net pay has moved more than twenty percent since the last period, before the run is approved rather than after someone complains. thresholds per organisation, an obvious way to acknowledge a flag, and the flags need to survive a recalculation of the run without being silently cleared", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "the `Run` entity collides with three other Runs across the java service — the payroll one, an import run, a robot cell test run — and every import block has to disambiguate. rename the payroll one throughout, including the JPA table mapping if that can be done without a migration, and check nothing depends on the class name reflectively", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "who else defines a `Run` type?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "why does row state recompute constantly?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "one employee builder for the tests", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt":"I inherited FoxglovePineMetricsStore and need a careful read of projects/foxglove/services/ledger/replay.go before I can sign off on the next release. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to FoxglovePineMetricsStore and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveLumenChartStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/foxglove/cmd/exporter/main.py and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveNimbusFormCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Two asks around FoxgloveSableParserCoordinator: (1) assess ownership and failure handling in projects/foxglove/db/migrations/20260730_events.sql; (2) capture the contract and rollback note for consumers. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"What does FoxgloveHarborIndexStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Sable: Two deliverables are holding up FoxgloveFernSnapshotCoordinator. First, assess ownership and failure handling in projects/foxglove/Sources/App/SessionStore.swift. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/foxglove/Sources/App/SessionStore.swift, which follows Cloudflare Workers conventions and currently suffers from an accessibility label that reads the internal enum. Cover the awkward empty and retry states.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Tide: projects/foxglove/ui/settings/PrivacyPane.tsx の FoxgloveSummitProxyFlow で、GraphQL の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- GraphQL を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は FoxgloveSummitProxyFlow のみ","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"ja"}
{"prompt":"Release engineering needs a FoxgloveKiteSchedulerService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"For FoxgloveGarnetModalCoordinator, change FoxgloveGarnetModalCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, give the existing implementation a read-only safety pass. Work from projects/foxglove/internal/auth/refresh.go, stay with Kafka, and cover the awkward empty and retry states. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-46118\n\n08:02 deploy FoxgloveCedarPolicyFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nUsing this as the starting evidence, propose a staged FoxgloveCedarPolicyFlow migration with compatibility seams, owners, canary metrics, rollback gates, and a no-code first milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveAcornWidgetCoordinator is blocking the next release because an empty state that flashes before cached data arrives. I need two concrete outcomes from a single pass: change FoxgloveAcornWidgetCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing Spring Boot conventions in projects/foxglove/db/migrations/20260730_events.sql; cover the awkward empty and retry states. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_46157'\n AND e.created_at >= now() - interval '24 hours'\nGROUP BY e.tenant_id, e.stream_id;\n\nHashAggregate (cost=184922.10..185011.81 rows=8971 width=40) (actual time=8421.294..8422.551 rows=123 loops=1)\n Group Key: e.tenant_id, e.stream_id\n Batches: 1 Memory Usage: 945kB\n -> Hash Join (cost=2118.42..181004.17 rows=522391 width=32) (actual time=42.118..8279.405 rows=918412 loops=1)\n Hash Cond: ((e.tenant_id = s.tenant_id) AND (e.stream_id = s.id))\n -> Bitmap Heap Scan on event_log e (actual time=18.602..7922.884 rows=1261044 loops=1)\n Recheck Cond: (tenant_id = 't_46157'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDeliver the FoxgloveBeaconStoreCoordinator server-side capability implied above: durable cursors, tenant authorization, idempotent retries, bounded work, telemetry, and focused integration coverage.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Pin FoxgloveAsterWebhookService's Kafka dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Umbra: Ticket OPS-46155: retire the legacy replay path for FoxgloveAmberFilterCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible FoxgloveAmberFilterCoordinator rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Split FoxgloveCedarPolicyStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveBasilRunnerCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Bring FoxgloveMapleQueueStore's confirmation sheet in line with the design tokens, including destructive emphasis, dark appearance, Dynamic Type, and swipe-to-dismiss behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Vela: Two deliverables are holding up FoxgloveQuartzPlayerCoordinator. First, separate FoxgloveQuartzPlayerCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/foxglove/ui/settings/PrivacyPane.tsx, which follows GraphQL conventions and currently suffers from a flaky snapshot caused by locale-dependent sorting. Cover the awkward empty and retry states.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveBirchMigratorCoordinator: handle the lingering thing","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'FoxglovePrismCacheFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[FoxglovePrismCacheFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/foxglove/cmd/exporter/main.py:144: error: -[FoxglovePrismCacheFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[FoxglovePrismCacheFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Bring FoxglovePrismCacheFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Willow: The first FoxgloveAtlasSearchFlow request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveVelaDrawerCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Xylem: Ticket OPS-46141: retire the legacy replay path for FoxgloveSpruceDaemonFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current FoxgloveSpruceDaemonFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Three teams extended FoxgloveAmberFilterService independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Separate those responsibilities into focused units, remove the duplicated normalization branches, and keep public types, wire values, log fields, timing, and test-observable behavior exactly the same.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Spring Boot operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"FoxgloveHarborIndexCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Yarrow: The API work is done; what remains for FoxgloveAcornWidgetStore is the visible interaction layer across loading, offline, empty, and success cases. Bring the drawer and detail pane to production polish with fluid sizing, honest skeletons, focus restoration, accessible announcements, and touch targets that survive large text.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveAcornWidgetStore\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Zephyr: Two asks around FoxgloveMoonlitSDKCoordinator: (1) finish FoxgloveMoonlitSDKCoordinator's responsive empty and retry states; (2) give the existing implementation a read-only safety pass. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"A previously stable test around FoxgloveOrbitSyncFlow now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveRainfallDBCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Checkout: Incident timeline — INC-46130\n\n08:02 deploy FoxgloveSableParserFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nUsing this as the starting evidence, propose a staged FoxgloveSableParserFlow migration with compatibility seams, owners, canary metrics, rollback gates, and a no-code first milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"For FoxglovePrismCacheCoordinator, finish FoxglovePrismCacheCoordinator's responsive empty and retry states; once that is complete, correct the known stale timeout beside it. Work from projects/foxglove/ml/pipeline/features.py, stay with Cloudflare Workers, and cover the awkward empty and retry states. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Does FoxgloveCoralUploadFlow enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"// projects/foxglove/pkg/cache/lease.rs\nfinal class FoxgloveCinderAuthFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit FoxgloveCinderAuthFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveBeaconStoreFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/foxglove/services/ledger/replay.go and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Exporter: Incident timeline — INC-46150\n\n08:02 deploy FoxgloveMarbleTokenCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the FoxgloveMarbleTokenCoordinator decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Why does FoxgloveBeaconStoreStore's Kafka worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Scheduler: Incident timeline — INC-46124\n\n08:02 deploy FoxgloveCraneWorkspaceFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the material above into a concise FoxgloveCraneWorkspaceFlow release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"Extract FoxgloveFernSnapshotService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"A copied hex color in FoxgloveWrenExportFlow lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for FoxgloveLedgerGateCoordinator:\n- primary outcome: produce a consumer guide for FoxgloveLedgerGateCoordinator\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/foxglove/apps/console/routes/usage.svelte\n- platform constraint: Spring Boot\n- known complication: lease renewal code copied across three workers\n\nBoth results are required, but they should remain independently reviewable. Cover the awkward empty and retry states; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Spell FoxgloveGarnetModalStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"FoxgloveDriftConsoleCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"FoxgloveTideWorkerCoordinator needs a paired pass: produce a consumer guide for FoxgloveTideWorkerCoordinator, plus give the existing implementation a read-only safety pass. Use projects/foxglove/app/src/main/SyncWorker.kt as the source of truth, preserve the Spring Boot contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"The FoxgloveMicaProfileStore surface in projects/foxglove/services/ledger/replay.go is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Why does FoxgloveVelaDrawerStore's Cloudflare Workers worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"# projects/foxglove/ui/settings/PrivacyPane.tsx\n[worker.foxglovecopperbridgeflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovecopperbridgeflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovecopperbridgeflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveCopperBridgeFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46121\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/foxglove/ui/settings/PrivacyPane.tsx and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"We need to move FoxgloveFlintTimelineStore from the legacy store to GraphQL. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"FoxgloveCloudReconcilerCoordinator: polish, then correct","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Give FoxgloveAsterWebhookStore a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a FoxgloveBirchMigratorStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"We need to move FoxgloveMarbleTokenStore from the legacy store to Spring Boot. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"What sequence would let FoxgloveSpruceDaemonStore adopt GraphQL with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind FoxgloveBirchMigratorService's Spring Boot choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"PM is preparing the FoxgloveFrostPanelService rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveFrostPanelService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Dashboard: projects/foxglove/ui/settings/PrivacyPane.tsx has grown through several launches, and FoxgloveSummitProxyService now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing GraphQL deployment\n- keep the work scoped to FoxgloveSummitProxyService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/foxglove/internal/auth/refresh.go b/projects/foxglove/internal/auth/refresh.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/internal/auth/refresh.go\n+++ b/projects/foxglove/internal/auth/refresh.go\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is FoxgloveBasilRunnerFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Worker: // projects/foxglove/config/staging.toml\nfinal class FoxgloveAtlasSearchCoordinatorCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Walk through what the artifact proves about FoxgloveAtlasSearchCoordinator; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveSpruceDaemonCoordinator: could this be clearer","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-46137: retire the legacy replay path for FoxgloveMicaProfileFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. From this evidence, draft consumer-facing migration guidance for FoxgloveMicaProfileFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Simulator: // projects/foxglove/infra/modules/edge/main.tf\nfinal class FoxgloveFrostPanelFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nRestructure FoxgloveFrostPanelFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveLumenChartCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current FoxgloveJuniperCLIStore design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveJuniperCLIStore\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveEmberRelayCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-46152\n\n08:02 deploy FoxgloveMosaicGridCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for FoxgloveMosaicGridCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Style FoxgloveLedgerGateService's offline state","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveDeltaCanvasCoordinator needs a paired pass: ship the idempotent FoxgloveDeltaCanvasCoordinator replay endpoint, plus capture the contract and rollback note for consumers. Use projects/foxglove/ui/settings/PrivacyPane.tsx as the source of truth, preserve the GraphQL contract, and avoid unrelated cleanup.","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Serve FoxglovePrismCacheService health checks","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-46122: retire the legacy replay path for FoxgloveAsterWebhookFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess FoxgloveAsterWebhookFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Runbook: projects/foxglove/infra/modules/edge/main.tf now contains FoxgloveBasilRunnerStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveFlintTimelineCoordinator: sort out the rough edge","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new FoxgloveAmberFilterStore adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Since the last release, FoxgloveSlateEditorService has shown a feature flag whose default differs between environments; nobody on the team can reproduce it reliably on a laptop. Trace task lifetime, cursor advancement, and durable acknowledgment across reconnects; produce a defensible root cause and the smallest experiment that would falsify it.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to FoxgloveSlateEditorService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Trace: projects/foxglove/app/src/main/SyncWorker.kt 里的 FoxgloveRavenSessionService 最近在 Spring Boot 流程中出现间歇性问题。 请写一份面向调用方的说明，包含 contract、错误、retry 和可复制示例，不要改 handler。\n\n约束：\n- 继续使用 Spring Boot\n- 保持兼容性和取消语义\n- 改动只限于 FoxgloveRavenSessionService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"zh"}
{"prompt":"FoxgloveAsterWebhookCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Diff: projects/foxglove/services/ledger/replay.go has grown through several launches, and FoxgloveBeaconStoreService now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to FoxgloveBeaconStoreService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Before we approve FoxgloveCinderAuthStore, assess whether two validators with subtly different error strings is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The FoxgloveAmberFilterFlow surface in projects/foxglove/apps/console/routes/usage.svelte is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveCedarPolicyCoordinator: diagnose, then correct","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Profiler: The FoxgloveLumenChartService empty state in projects/foxglove/ml/pipeline/features.py needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating an accessibility label that reads the internal enum in FoxgloveMosaicGridStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Does FoxgloveCloudReconcilerService preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Extract FoxgloveOspreyJobStore's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"FoxgloveAtlasSearchStore's metric is misspelled as succesful_total in one declaration. Correct that literal and its exact test expectation, without renaming anything else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"// projects/foxglove/engine/render/atlas.cpp\nfinal class FoxgloveFlintTimelineFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nRestructure FoxgloveFlintTimelineFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Introduce a durable deduplication key for FoxgloveDriftConsoleService events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"FoxgloveSlateEditorCoordinator is blocking the next release because timestamps rendered one day ahead near UTC midnight. I need two concrete outcomes from a single pass: assess ownership and failure handling in projects/foxglove/packages/api/openapi.yaml, and capture the contract and rollback note for consumers. Use the existing Kotlin coroutines conventions in projects/foxglove/packages/api/openapi.yaml; cover the awkward empty and retry states. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveCopperBridgeCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Make FoxgloveJuniperCLIService keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Console: # projects/foxglove/ml/pipeline/features.py\n[worker.foxglovewrenexportcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovewrenexportcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovewrenexportcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveWrenExportCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46159\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nMake the one confirmed configuration correction in projects/foxglove/ml/pipeline/features.py. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveCinderAuthCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"FoxglovePineMetricsCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Give FoxgloveEchoRegistryStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Decouple FoxgloveDeltaCanvasService's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Summarize the FoxgloveCopperBridgeService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The behavior of FoxgloveLedgerGateStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/foxglove/apps/console/routes/usage.svelte. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Spring Boot operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Describe FoxgloveOpalRouterService's error envelope","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"// projects/foxglove/engine/render/atlas.cpp\nfinal class FoxgloveJuniperCLIFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate FoxgloveJuniperCLIFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Workspace: Ticket OPS-46131: retire the legacy replay path for FoxgloveDeltaCanvasFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nAssess FoxgloveDeltaCanvasFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Por que FoxgloveNovaPickerService trava?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"pt"}
{"prompt":"FoxgloveKiteSchedulerCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Store FoxgloveCloudReconcilerStore's delivery receipts","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"FoxgloveRavenSessionCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Repository: // projects/foxglove/infra/modules/edge/main.tf\nfinal class FoxgloveGarnetModalFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit FoxgloveGarnetModalFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a FoxgloveMosaicGridFlow changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Pipeline: # projects/foxglove/src/sync/reconcile.ts\n[worker.foxgloveacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxgloveacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxgloveacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46110\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nAlign FoxgloveAcornWidgetFlow's staging timeout with the shown production value and refresh only the focused config test; nothing else in the paste should move.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"En projects/foxglove/ui/settings/PrivacyPane.tsx, FoxgloveQuartzPlayerStore tiene un problema intermitente en el flujo de GraphQL. Propón fases, compatibilidad, métricas, rollback y ownership; detente antes de tocar código.\n\nRestricciones:\n- seguir con GraphQL\n- conservar compatibilidad y cancelación\n- limitar el cambio a FoxgloveQuartzPlayerStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con GraphQL alrededor de FoxgloveQuartzPlayerStore.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"es"}
{"prompt":"Gateway: Ticket OPS-46135: retire the legacy replay path for FoxgloveRavenSessionFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nMap a safe route from the current FoxgloveRavenSessionFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Renderer: The name pendingAck means two different things across FoxgloveNimbusFormService's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"For FoxgloveOpalRouterCoordinator, assess ownership and failure handling in projects/foxglove/engine/render/atlas.cpp; once that is complete, capture the contract and rollback note for consumers. Work from projects/foxglove/engine/render/atlas.cpp, stay with GraphQL, and cover the awkward empty and retry states. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveEchoRegistryCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new FoxgloveVelaDrawerService adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Read projects/foxglove/Sources/App/SessionStore.swift and tell me whether FoxgloveWillowCodecService can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Could FoxgloveMarbleTokenFlow show the active Spring Boot sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Since the last release, FoxgloveCoralUploadStore has shown a misleading timeout name used in five packages; nobody on the team can reproduce it reliably on a laptop. Trace task lifetime, cursor advancement, and durable acknowledgment across reconnects; produce a defensible root cause and the smallest experiment that would falsify it.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to FoxgloveCoralUploadStore and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Center the FoxgloveTideWorkerStore modal","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Spell FoxgloveCraneWorkspaceStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-46123: retire the legacy replay path for FoxgloveCloudReconcilerFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCapture the FoxgloveCloudReconcilerFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveJuniperCLICoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Two asks around FoxgloveNovaPickerCoordinator: (1) change FoxgloveNovaPickerCoordinator's known staging timeout from 15 to 30 seconds; (2) capture the contract and rollback note for consumers. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"FoxgloveKiteSchedulerStore's staging timeout is already known to be wrong: change the single projects/foxglove/pkg/cache/lease.rs value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Trace FoxgloveHarborIndexService's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current FoxgloveWrenExportService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveWrenExportService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two asks around FoxgloveCraneWorkspaceCoordinator: (1) find the unknown cause of a deadlock that appears only during shutdown; (2) correct the known stale timeout beside it. Cover the awkward empty and retry states, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"UI ticket DES-46154: finish the compact FoxgloveIrisBatchCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/foxglove/Sources/CLI/Commands/Doctor.swift\nFramework: Cloudflare Workers\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible FoxgloveIrisBatchCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Indexer: // projects/foxglove/Sources/CLI/Commands/Doctor.swift\nfinal class FoxgloveFernSnapshotFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nAdd the bounded FoxgloveFernSnapshotFlow replay flow described here, including authorization, key rotation, cancellation, lag metrics, and tests for malformed and cross-tenant cursors.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/foxglove/ml/pipeline/features.py b/projects/foxglove/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/ml/pipeline/features.py\n+++ b/projects/foxglove/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is FoxgloveLumenChartFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-46126\n\n08:02 deploy FoxgloveOpalRouterFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current FoxgloveOpalRouterFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"The data is already available in projects/foxglove/Sources/CLI/Commands/Doctor.swift; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Split FoxgloveOspreyJobService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"FoxgloveMapleQueueCoordinator: polish the last piece","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Apparently: # projects/foxglove/apps/console/routes/usage.svelte\n[worker.foxgloveechoregistryflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxgloveechoregistryflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxgloveechoregistryflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveEchoRegistryFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46145\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 The intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/foxglove/apps/console/routes/usage.svelte and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Milestones for replacing FoxglovePineMetricsService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Does FoxglovePrismCacheStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: FoxgloveAcornWidgetService has one known configuration mistake in projects/foxglove/src/sync/reconcile.ts, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to FoxgloveAcornWidgetService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"// projects/foxglove/Sources/App/SessionStore.swift\nfinal class FoxgloveWillowCodecFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nWalk through what the artifact proves about FoxgloveWillowCodecFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Fresh release brief for FoxgloveFrostPanelCoordinator:\n- primary outcome: change FoxgloveFrostPanelCoordinator's known staging timeout from 15 to 30 seconds\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/foxglove/internal/auth/refresh.go\n- platform constraint: Kafka\n- known complication: lost focus when the drawer animation finishes\n\nBoth results are required, but they should remain independently reviewable. Cover the awkward empty and retry states; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-46143: retire the legacy replay path for FoxgloveEmberRelayFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible FoxgloveEmberRelayFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/foxglove/ml/pipeline/features.py b/projects/foxglove/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/ml/pipeline/features.py\n+++ b/projects/foxglove/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate FoxgloveRainfallDBFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a FoxgloveNimbusFormStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveMicaProfileCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Give FoxgloveMapleQueueService's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Warum hängt FoxgloveRainfallDBStore?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"Lately: // projects/foxglove/engine/render/atlas.cpp\nfinal class FoxgloveOrbitSyncCoordinatorCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nSplit FoxgloveOrbitSyncCoordinator by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Oddly: diff --git a/projects/foxglove/app/src/main/SyncWorker.kt b/projects/foxglove/app/src/main/SyncWorker.kt\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/app/src/main/SyncWorker.kt\n+++ b/projects/foxglove/app/src/main/SyncWorker.kt\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure FoxgloveLedgerGateFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Map FoxgloveCopperBridgeStore's ownership split","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Dedupe FoxgloveCedarPolicyService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"On compact widths, FoxgloveIrisBatchFlow's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"The minimum supported GraphQL version in projects/foxglove/engine/render/atlas.cpp is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-46134\n\n08:02 deploy FoxgloveNimbusFormFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for FoxgloveNimbusFormFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Design the FoxgloveGarnetModalService rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Corrige le timeout de FoxgloveNovaPickerStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"fr"}
{"prompt":"Move FoxgloveSpruceDaemonService's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Store FoxgloveTideWorkerService's delivery receipts","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Pin FoxgloveSableParserService's Spring dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"projects/foxglove/packages/api/openapi.yaml の FoxgloveEmberRelayService で、Kotlin coroutines の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- Kotlin coroutines を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は FoxgloveEmberRelayService のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"ja"}
{"prompt":"Please resist widening this one: FoxgloveSlateEditorStore works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveSlateEditorStore\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe cause and exact value change are already known, so keep this as a contained correction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-46128: finish the compact FoxgloveOspreyJobFlow filter experience\n\nRoute: /catalog/search\nSource: projects/foxglove/crates/index/src/segment.rs\nFramework: Kotlin coroutines\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nUse the UI evidence to complete FoxgloveOspreyJobFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Why does FoxgloveSummitProxyStore's GraphQL worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'FoxgloveVelaDrawerFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[FoxgloveVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/foxglove/cmd/exporter/main.py:144: error: -[FoxgloveVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding] : XCTAssertEqual failed: (\"Optional(4)\") is not equal to (\"Optional(3)\")\nAccessibility hierarchy at failure:\n Application, 0x104c, pid: 812\n Window, identifier: \"main\"\n NavigationStack, identifier: \"catalog\"\n Button, label: \"Filters\", value: \"2 active\"\n CollectionView, identifier: \"results-grid\", rows: 24\n Sheet, identifier: \"filter-sheet\"\n TextField, label: \"Search filters\", value: \"\"\n Switch, label: \"Available offline\", value: \"1\"\n Button, label: \"Apply\", enabled: true\nTest Case '-[FoxgloveVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nUse the UI evidence to complete FoxgloveVelaDrawerFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Currently: diff --git a/projects/foxglove/workers/thumbnail/consumer.ex b/projects/foxglove/workers/thumbnail/consumer.ex\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/workers/thumbnail/consumer.ex\n+++ b/projects/foxglove/workers/thumbnail/consumer.ex\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nSplit FoxgloveQuartzPlayerFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Today: // projects/foxglove/db/migrations/20260730_events.sql\nfinal class FoxgloveBirchMigratorFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate FoxgloveBirchMigratorFlow's parallel adapters behind a single internal boundary, with no changes to API, timing, serialization, metrics, or error text.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveOspreyJobCoordinator needs a paired pass: produce a consumer guide for FoxgloveOspreyJobCoordinator, plus give the existing implementation a read-only safety pass. Use projects/foxglove/pkg/cache/lease.rs as the source of truth, preserve the Kotlin coroutines contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Context: # projects/foxglove/workers/thumbnail/consumer.ex\n[worker.foxglovesummitproxycoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovesummitproxycoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovesummitproxycoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveSummitProxyCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46151\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nThe intended correction is already known: change only the stale 15-second setting to 30 seconds in projects/foxglove/workers/thumbnail/consumer.ex and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Background: projects/foxglove/config/staging.toml 里的 FoxgloveEmberRelayStore 最近在 Kotlin coroutines 流程中出现间歇性问题。 请给出阶段、兼容层、指标、rollback 和 ownership，先不要修改代码。\n\n约束：\n- 继续使用 Kotlin coroutines\n- 保持兼容性和取消语义\n- 改动只限于 FoxgloveEmberRelayStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"FoxgloveMosaicGridService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Kafka operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Question: diff --git a/projects/foxglove/config/staging.toml b/projects/foxglove/config/staging.toml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/foxglove/config/staging.toml\n+++ b/projects/foxglove/config/staging.toml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure FoxgloveMoonlitSDKFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Observation: Incident timeline — INC-46120\n\n08:02 deploy FoxgloveHarborIndexFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFind the source of this FoxgloveHarborIndexFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Constraint: The public surface of FoxgloveMarbleTokenService is frozen, but its internal ownership in projects/foxglove/db/migrations/20260730_events.sql is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveMarbleTokenService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/foxglove/engine/render/atlas.cpp, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Request: The public surface of FoxgloveOrbitSyncService is frozen, but its internal ownership in projects/foxglove/lib/codec/frame.cc is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside FoxgloveOrbitSyncService\n- cover the awkward empty and retry states\n\nSeveral teams work in this observability, SwiftUI, Redis monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Goal: # projects/foxglove/apps/console/routes/usage.svelte\n[worker.foxglovetideworkerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.foxglovetideworkerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.foxglovetideworkerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.FoxgloveTideWorkerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-46125\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nAlign FoxgloveTideWorkerFlow's staging timeout with the shown production value and refresh only the focused config test; nothing else in the paste should move.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Symptom: // projects/foxglove/web/components/FilterDrawer.vue\nfinal class FoxglovePineMetricsFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nWalk through what the artifact proves about FoxglovePineMetricsFlow; flag semantic changes and missing coverage with exact evidence, keeping this a read-only pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"FoxgloveWillowCodecCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Headsup: Incident timeline — INC-46146\n\n08:02 deploy FoxgloveDriftConsoleFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nTurn the artifact into a reversible FoxgloveDriftConsoleFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"FYI: Incident timeline — INC-46113\n\n08:02 deploy FoxgloveSlateEditorFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Reconstruct the FoxgloveSlateEditorFlow failure timeline, test competing hypotheses against the pasted evidence, and identify the first broken invariant rather than treating later warnings as causes.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Meanwhile: Incident timeline — INC-46148\n\n08:02 deploy FoxgloveKiteSchedulerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why FoxgloveKiteSchedulerFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-46158\n\n08:02 deploy FoxgloveCoralUploadCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFrom this evidence, draft consumer-facing migration guidance for FoxgloveCoralUploadCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"pasted-context","lang":"en"}
{"prompt":"Split FoxgloveOpalRouterStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Design the FoxgloveSableParserStore rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Locally: projects/foxglove/pkg/cache/lease.rs now contains FoxgloveCinderAuthService's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Polish the FoxgloveDeltaCanvasStore toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"FoxgloveCoralUploadService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Kotlin coroutines operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"The minimum supported Kafka version in projects/foxglove/internal/auth/refresh.go is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Production: The FoxgloveEchoRegistryService surface in projects/foxglove/apps/console/routes/usage.svelte is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Em projects/foxglove/apps/console/routes/usage.svelte, o FoxgloveRavenSessionStore tem um problema intermitente no fluxo de Spring Boot. Leia o fluxo atual e avalie ownership, cancelamento e ordem; preciso apenas da análise.\n\nRestrições:\n- continuar com Spring Boot\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao FoxgloveRavenSessionStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"A copied hex color in FoxgloveMicaProfileService lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"En projects/foxglove/packages/api/openapi.yaml, FoxgloveAtlasSearchService tiene un problema intermitente en el flujo de Kotlin coroutines. Lee el flujo actual y dime si ownership, cancelación y orden son seguros; solo necesito el análisis.\n\nRestricciones:\n- seguir con Kotlin coroutines\n- conservar compatibilidad y cancelación\n- limitar el cambio a FoxgloveAtlasSearchService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"Any races in FoxgloveMoonlitSDKService?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Ownership of FoxgloveWrenExportStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Cloudflare Workers operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"In projects/foxglove/workers/thumbnail/consumer.ex hat FoxgloveQuartzPlayerService ein sporadisches Problem im GraphQL-Ablauf. Lies den aktuellen Ablauf und bewerte Ownership, Abbruch und Reihenfolge; ich brauche nur die Analyse.\n\nRandbedingungen:\n- GraphQL weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf FoxgloveQuartzPlayerService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um FoxgloveQuartzPlayerService mit GraphQL kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"de"}
{"prompt":"Read projects/foxglove/engine/render/atlas.cpp and tell me whether FoxgloveOrbitSyncStore can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Clarify FoxgloveMoonlitSDKStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"FoxgloveFrostPanelStore needs a production server path for replaying tenant events; the public envelope is agreed but persistence and retry handling are not wired. Implement the endpoint and durable cursor, enforce tenant authorization and idempotency, emit useful spans, cap work per request, and include focused tests for retries, cancellation, and malformed cursors.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- cover the awkward empty and retry states\n- retain the current Kafka operational envelope\n\nThis repository spans observability, SwiftUI, Redis; use its existing conventions rather than importing a new abstraction.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-46147: retire the legacy replay path for FoxgloveMapleQueueFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCapture the FoxgloveMapleQueueFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Cadre la migration de FoxgloveRainfallDBService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"fr"}
{"prompt":"Make FoxgloveCraneWorkspaceService keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about FoxgloveFernSnapshotStore, but the current prose in projects/foxglove/Sources/App/SessionStore.swift only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to FoxgloveFernSnapshotStore and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: FoxgloveIrisBatchService has one known configuration mistake in projects/foxglove/Sources/App/SessionStore.swift, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover the awkward empty and retry states\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to FoxgloveIrisBatchService and its direct tests\n\nThe relevant code crosses observability, SwiftUI, Redis. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The FoxgloveWillowCodecStore feature flag default should be false in test, exactly like production; correct that config entry and nothing else.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-46127\n\n08:02 deploy FoxgloveNovaPickerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why FoxgloveNovaPickerFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
data/round2-07.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "extension hangs the whole editor on large repos and this is the profile:\n\nExtension host CPU profile (10s):\n 92.1% (program)\n 88.4% onDidChangeTextDocument\n 86.9% IndexManager.reindexAll\n 84.2% glob('**/*.{ts,tsx,js,jsx}')\n 1.8% ts.createSourceFile\n 3.1% provideCompletionItems\n\nExtension 'lumen.navigator' caused the extension host to become unresponsive.\n[Warning] UNRESPONSIVE extension host: 'lumen.navigator' took 8412ms\n[Info] Extension host terminated unexpectedly 3 times within the last 5 minutes.\n\nreindexAll runs on every keystroke in a workspace with 40,000 files", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "seat maps render wrong for one aircraft type and support sent me the payload:\n\n{\n \"equipment\": \"77W\",\n \"cabins\": [\n {\"class\": \"J\", \"rows\": [{\"number\": 1, \"seats\": [\"A\",\"C\",\"D\",\"G\",\"H\",\"K\"]}]},\n {\"class\": \"W\", \"rows\": [{\"number\": 20, \"seats\": [\"A\",\"B\",\"C\",\"D\",\"E\",\"F\",\"G\",\"H\",\"J\",\"K\"]}]},\n {\"class\": \"Y\", \"rows\": [{\"number\": 30, \"seats\": [\"A\",\"B\",\"C\",\"D\",\"E\",\"F\",\"G\",\"H\",\"J\",\"K\"]}]}\n ],\n \"exit_rows\": [20, 44],\n \"blocked\": [\"30A\", \"30K\"]\n}\n\nour renderer assumes 3-4-3 for wide bodies and lays out the J cabin as if it were economy, so business class shows ten seats across", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "supplier abstraction, three implementations behind it, and a fourth to be added next month:\n\nclass Supplier(Protocol):\n def search(self, query: SearchQuery) -> list[Offer]: ...\n def hold(self, offer_id: str, passengers: list[Passenger]) -> Hold: ...\n def confirm(self, hold_id: str, payment_ref: str) -> Booking: ...\n def cancel(self, record_locator: str) -> None: ...\n def refund(self, record_locator: str, amount: Decimal) -> str: ...\n\namadeus: hold expires in 20 minutes, cancel is free before ticketing\nsabre: no hold concept at all, we fake it with a 5 minute local reservation\ndirect_airline: hold is 60 minutes, cancel after ticketing costs a fee we can't know in advance\n\nis this interface honest about what these suppliers actually do?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "the extension keeps its index as one 40MB JSON blob rewritten in full on every change", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "our react app has three date formatting helpers and the checkout uses a fourth one inline", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "extension's activation events, which i suspect are why it shows up in every startup complaint:\n\n\"activationEvents\": [\"*\"],\n\"main\": \"./dist/extension.js\",\n\"contributes\": {\n \"commands\": [{ \"command\": \"lumen.goToSymbol\", \"title\": \"Lumen: Go to Symbol\" }],\n \"configuration\": {\n \"properties\": {\n \"lumen.indexOnSave\": { \"type\": \"boolean\", \"default\": true },\n \"lumen.excludeGlobs\": { \"type\": \"array\", \"default\": [] }\n }\n }\n}\n\nactivate() builds the whole index synchronously before returning, and the index is 40MB of JSON on a big repo", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "a colleague's PR for the search results page, and i can't decide whether the memoisation is helping:\n\n@@ -22,10 +22,26 @@ export function ResultsList({ results, filters }: Props) {\n- const visible = results.filter(r => matches(r, filters)).sort(byPrice)\n+ const visible = useMemo(\n+ () => results.filter(r => matches(r, filters)).sort(byPrice),\n+ [results, filters]\n+ )\n+ const rowRenderer = useCallback(\n+ (r: Result) => <ResultRow key={r.id} result={r} onSelect={onSelect} />,\n+ [onSelect]\n+ )\n return <div>{visible.map(rowRenderer)}</div>\n }\n\nfilters is an object literal built in the parent's render, onSelect is an inline arrow, and results is typically 200 items", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "supplier integration guide, written for amadeus and never updated. what's true across all three now:\n\n- amadeus: SOAP, session-based, sessions expire after 15 minutes of inactivity, hold 20 minutes\n- sabre: REST, bearer token valid 7 days, no hold, we fake it locally for 5 minutes\n- direct airline: REST, mTLS, hold 60 minutes, cancellation fees unknown until after ticketing\n- all three: record locators are 6 characters but sabre's are case-sensitive and the others aren't\n- error handling differs completely; only amadeus distinguishes \"sold out\" from \"price changed\"\n- rate limits: amadeus 10/s, sabre 50/s, direct airline unpublished and enforced by disconnection\n\nrewrite the guide so it covers all three honestly, for the engineer adding the fourth", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "extension has three code paths that build a file glob, and windows breaks two of them:\n\n// indexer.ts\nconst pattern = `${workspaceRoot}/**/*.{ts,tsx,js,jsx}`\n\n// watcher.ts\nconst pattern = new vscode.RelativePattern(folder, '**/*.ts')\n\n// symbols.ts\nconst pattern = path.join(workspaceRoot, '**', '*.ts')\n\nonly the RelativePattern one behaves correctly on windows; the other two mix separators and silently match nothing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "seat map, again", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "our API changelog needs an entry for the 410 on stale offer tokens, with what integrators should do", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "the results page needs a saved-search feature, since our repeat users run the same query daily", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "booking confirmations stopped for one airline integration and django is throwing this:\n\nTraceback (most recent call last):\n File \"/app/bookings/services/confirm.py\", line 141, in confirm\n pnr = supplier.retrieve(record_locator)\n File \"/app/suppliers/amadeus/client.py\", line 88, in retrieve\n return self._parse(resp.content)\n File \"/app/suppliers/amadeus/client.py\", line 212, in _parse\n return xmltodict.parse(content)[\"Envelope\"][\"Body\"][\"RetrievePNRReply\"]\nKeyError: 'RetrievePNRReply'\n\nresponse body (truncated):\n<soap:Envelope><soap:Body><soap:Fault><faultcode>SOAP-ENV:Server</faultcode>\n<faultstring>Session expired or invalid</faultstring></soap:Fault></soap:Body></soap:Envelope>\n\nabout 4% of confirmations, always the ones where the user took more than ten minutes on the payment page", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "celery workers stop consuming after a few hours, no errors anywhere:\n\n[2026-07-29 09:02:14,881: INFO/MainProcess] Task bookings.tasks.sync_pnr[8f2b1c] received\n[2026-07-29 09:02:15,102: INFO/ForkPoolWorker-4] Task bookings.tasks.sync_pnr[8f2b1c] succeeded in 0.21s\n[2026-07-29 09:14:02,441: INFO/MainProcess] Task bookings.tasks.sync_pnr[91cc40] received\n[2026-07-29 09:14:02,882: WARNING/ForkPoolWorker-2] supplier timeout, retrying in 60s\n[2026-07-29 09:15:03,114: WARNING/ForkPoolWorker-2] supplier timeout, retrying in 120s\n[2026-07-29 09:17:04,002: WARNING/ForkPoolWorker-2] supplier timeout, retrying in 240s\n[2026-07-29 09:21:05,118: WARNING/ForkPoolWorker-1] supplier timeout, retrying in 60s\n[2026-07-29 10:44:12,441: INFO/MainProcess] Task bookings.tasks.sync_pnr[aa1902] received\n\nafter that, nothing. inspect active shows four tasks, all sleeping in the retry backoff, and prefetch is 4", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "what does the silent passenger downgrade do?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "is the seat hold actually exclusive?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "extension's settings, documented nowhere except the schema. write the readme section:\n\n\"lumen.indexOnSave\": true // reindex changed files on save\n\"lumen.excludeGlobs\": [] // added to the built-in excludes, not replacing them\n\"lumen.maxIndexSizeMb\": 200 // index is dropped and rebuilt if it exceeds this\n\"lumen.symbolProviders\": [\"ts\", \"py\", \"go\"] // order matters, first match wins\n\"lumen.experimental.watchNodeModules\": false // enabling this on a monorepo will hang the host\n\"lumen.telemetry\": \"errors\" // off | errors | usage\n\nthings only we know: excludeGlobs are relative to the workspace root, not the file; the index rebuild on exceeding maxIndexSizeMb happens silently and can take minutes; symbolProviders order is why go-to-definition sometimes lands in a .d.ts", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "a customer wants ten thousand devices on a collector that struggles with fourteen hundred, and the current design spawns a goroutine per OID group with no per-device limit. i want to know what a version that scales looks like — whether that's worker pools, sharding by device, or splitting collection from evaluation entirely — and what we'd have to change in the on-premise deployment story to ship it to customers who upgrade by copying a binary", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "alerting rules we inherited from the previous team. worth keeping any of them?\n\n- alert: DeviceDown\n expr: up{job=\"snmp\"} == 0\n for: 0m\n labels: { severity: page }\n\n- alert: InterfaceErrors\n expr: rate(if_in_errors[5m]) > 0\n for: 1m\n labels: { severity: page }\n\n- alert: HighUtilisation\n expr: if_in_octets_rate / if_speed > 0.7\n for: 5m\n labels: { severity: page }\n\n- alert: CollectorLag\n expr: collector_scrape_duration_seconds > 25\n for: 10m\n labels: { severity: ticket }\n\nthe on-call gets about 40 pages a night and acknowledges most of them without looking", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "on-call handbook says \"see the wiki\" and the wiki is empty. what the team actually does:\n\n- pages come from prometheus into pagerduty, and the only real ones are CollectorLag and BookingFailureRate\n- DeviceDown pages 40 times a night and everyone acknowledges without looking, which is its own problem\n- for BookingFailureRate, first check which supplier — the dashboard has a breakdown, the alert doesn't\n- amadeus session expiry is the most common cause and clears itself; if it doesn't, restart the supplier worker\n- if bookings are failing at payment, check whether it's PriceChangedError before waking anyone\n- there is no runbook for the collector at all; the person who wrote it left in March\n\nwrite the on-call handbook, and flag where we're relying on one person's memory", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "three supplier clients each parse errors their own way, and two swallow the distinction we need:\n\n# amadeus/client.py\nif fault := body.get(\"Fault\"):\n raise SupplierError(fault[\"faultstring\"])\n\n# sabre/client.py\nif resp.status_code >= 400:\n raise SupplierError(f\"sabre returned {resp.status_code}\")\n\n# direct_airline/client.py\ntry:\n data = resp.json()\nexcept ValueError:\n raise SupplierError(\"bad response\")\nif data.get(\"errors\"):\n raise SupplierError(data[\"errors\"][0].get(\"detail\", \"unknown\"))\n\nthe booking flow needs to distinguish sold-out, price-changed, session-expired and everything else, and only amadeus surfaces that today", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "price breakdown needs table headers", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "one retry policy across the integrations", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "we silenced a paging alert twice in one night rather than investigate, and the underlying cause was a firmware upgrade changing an SNMP response size. write the incident report, and be straight about the silencing — including that the rule had been noisy for months and everyone knew the report goes to the whole engineering group, not just our team.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "is our price guarantee real?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "celery stops consuming after a few hours", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "booking thing from yesterday", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "what does our extension do when two workspace folders have conflicting index versions", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "refunds are being issued twice for a handful of cancellations, here's the audit trail for one:\n\n11:02:14 POST /api/bookings/88412/cancel user=4471 → 202 accepted\n11:02:14 task refund.issue queued id=8f2b1c booking=88412 amount=214.00\n11:02:44 task refund.issue started id=8f2b1c\n11:03:14 supplier call timed out after 30s\n11:03:14 task refund.issue retry 1 queued id=8f2b1c\n11:03:16 supplier webhook received: refund CONFIRMED ref=RF-990412 amount=214.00\n11:04:14 task refund.issue started id=8f2b1c (retry 1)\n11:04:19 supplier call succeeded ref=RF-990418 amount=214.00\n11:04:19 booking 88412 marked refunded\n\nthe supplier's first call did go through, it just answered slowly", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "e2e suite fails on CI roughly one run in four, always in the seat selection step:\n\n 1) booking flow › selects a seat and continues\n TimeoutError: locator.click: Timeout 30000ms exceeded.\n Call log:\n - waiting for locator('[data-seat=\"12A\"]')\n - locator resolved to <button data-seat=\"12A\" disabled>…</button>\n - attempting click action\n - element is not enabled - waiting...\n\n 2) booking flow › shows the price breakdown\n Error: expect(received).toBe(expected)\n Expected: \"€214.00\"\n Received: \"€214.00 \"\n\n 2 failed, 88 passed (4m 12s)\n\nthe seat becomes enabled once the availability websocket delivers, which locally is instant", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "before i sign off on this, does the locking do what the author thinks?\n\[email protected]\ndef hold_seat(booking_id, seat):\n booking = Booking.objects.select_for_update().get(pk=booking_id)\n existing = SeatHold.objects.filter(flight=booking.flight, seat=seat, released_at__isnull=True)\n if existing.exists():\n raise SeatTaken(seat)\n hold = SeatHold.objects.create(booking=booking, flight=booking.flight, seat=seat,\n expires_at=timezone.now() + timedelta(minutes=15))\n cache.set(f\"seat:{booking.flight_id}:{seat}\", booking_id, 900)\n return hold\n\nfour web workers, postgres read committed, and seat holds also expire via a celery beat task that runs every minute", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "price-lock design, as it exists in the code. is the fifteen minutes real?\n\n1. search caches supplier prices in redis for 300s, keyed on (origin, destination, date, cabin)\n2. adding to cart writes a PriceLock row with expires_at = now + 15 minutes and the cached price\n3. the payment page re-reads the PriceLock but does not re-check the supplier\n4. on submit, the payment service calls the supplier to confirm availability, which returns the live price\n5. if the live price differs by more than 1%, we raise PriceChangedError and the user starts again\n6. there is no step that refreshes the lock or holds inventory with the supplier\n\nmarketing tells customers the price is guaranteed for fifteen minutes", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "por favor, dá uma olhada nisto antes de irmos para produção:\n\n@api_view([\"POST\"])\ndef refund(request, booking_id):\n booking = get_object_or_404(Booking, pk=booking_id)\n if booking.status != \"cancelled\":\n return Response({\"error\": \"not cancelled\"}, status=400)\n amount = booking.total - booking.fees\n ref = supplier.refund(booking.record_locator, amount)\n booking.status = \"refunded\"\n booking.refund_ref = ref\n booking.save()\n send_refund_email.delay(booking.id)\n return Response({\"ref\": ref})\n\nnão há idempotência nenhuma, o supplier demora às vezes 30 segundos, e o cliente pode carregar duas vezes", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "pt"}
{"prompt": "changelog for the collector, from the commits since 3.1:\n\n41c9e0b fix(snmp): raise the response buffer to 64KB\n88f21c0 feat(poll): per-device concurrency limit\nc0aa774 fix(alert): DeviceDown now requires two consecutive failures\n2e91b45 perf: reuse SNMP sessions instead of dialling per group\naa30f19 feat(api): /v1/devices/{id}/interfaces with pagination\n9c1d004 chore: drop support for SNMPv1\n4410bb7 fix(metrics): interface counters no longer reset on rediscovery\nb77e910 feat(config): per-device polling interval\n\nour users are network engineers who run this on-premise; two of these change alerting behaviour and one is a breaking change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "playwright config and the CI job, and the flakes are all timing:\n\n// playwright.config.ts\nexport default defineConfig({\n timeout: 30_000,\n expect: { timeout: 5_000 },\n retries: 0,\n workers: 8,\n use: { baseURL: process.env.BASE_URL, trace: 'off', actionTimeout: 0 },\n})\n\n# ci.yml\n- run: docker compose up -d\n- run: npx playwright test\n env:\n BASE_URL: http://localhost:8000\n\nno wait for the app to be ready, no retries, eight workers against one container, and traces are off so we can never see what happened", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "django settings diff between environments, one of these explains the session bug:\n\n# base.py\nSESSION_COOKIE_AGE = 1209600\nSESSION_ENGINE = \"django.contrib.sessions.backends.db\"\nCACHES = {\"default\": {\"BACKEND\": \"django_redis.cache.RedisCache\", \"LOCATION\": REDIS_URL}}\n\n# production.py\nSESSION_ENGINE = \"django.contrib.sessions.backends.cache\"\nSESSION_CACHE_ALIAS = \"default\"\nCACHES[\"default\"][\"OPTIONS\"] = {\"MAX_ENTRIES\": 10000, \"CULL_FREQUENCY\": 3}\n\n# staging.py\nSESSION_ENGINE = \"django.contrib.sessions.backends.db\"\n\nusers report being logged out mid-booking in production only, and the cache also holds our search results", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependabot batch on the django app, which of these can go in today:\n\ndjango 5.0.7 -> 5.1.2 (minor; release notes mention a change to `Model.save()` positional args)\ncelery 5.3.6 -> 5.4.0 (minor; prefetch behaviour changed for long-running tasks)\nrequests 2.31.0 -> 2.32.4 (advisory: certificate verification bypass in rare configurations)\nxmltodict 0.13.0 -> 0.14.2 (minor; namespace handling changed)\n\nour amadeus client is the only thing using xmltodict, and it parses namespaced SOAP", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "device model has grown fields for every vendor quirk and it's now unreadable:\n\ntype Device struct {\n\tID, Name, Address string\n\tCommunity string // v2c only\n\tUsername, AuthKey, PrivKey string // v3 only\n\tAuthProto, PrivProto string // v3 only\n\tUseBulk bool\n\tMaxRepetitions int\n\tBufferBytes int\n\tSkipInterfaces []string\n\tVendorQuirks map[string]string // \"cisco_ifindex_shift\": \"1\", etc\n\tPollInterval time.Duration\n\tLastSeen time.Time\n\tConsecutiveFails int\n}\n\nhalf these fields are only meaningful for one SNMP version, and VendorQuirks is read by string key in six places", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "collector's future, as the team sees it. i need this turned into a plan i can defend:\n\n- 1,400 devices today, a customer wants 10,000 next year\n- one process, one goroutine per OID group, no per-device limits, which is why it falls over\n- SNMPv1 support was dropped last month and two customers noticed\n- gNMI streaming telemetry is what the newer devices want, and we don't support it\n- the alerting rules are unusable and everyone silences them\n- on-premise customers upgrade by copying a binary, and we have no migration story for config\n- one engineer knows the SNMP internals, and it isn't me", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "search cache TTL down to 60s", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "snmp buffer to 64KB in prod", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "per-device concurrency cap of 4", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "i'd like to understand what happens to a seat hold when the booking is abandoned at payment", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "one error taxonomy for suppliers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "alerting is so noisy that on-call acknowledges without reading, which is how a real outage went unnoticed for six hours last month. rather than tune individual rules i'd like a view on what our alerting should be built around — symptoms rather than causes, what deserves a page versus a ticket, and how we'd know whether the change worked", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "price guarantee we advertise is a marketing promise with no technical backing, and support answers the resulting complaints from memory. write the help centre article that explains honestly what our price lock does and doesn't do, why a price can change at payment, and what a customer can do about it — without either lying or making us sound careless", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "on-call handbook says \"see the wiki\" and the wiki is empty, so everything lives in one person's memory — including the fact that half our pages are known-noisy and which supplier failure clears itself. write the handbook properly, and mark clearly every place where the honest answer is that only one person knows", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "three supplier clients parse errors three different ways and two of them collapse everything into a single exception type, so the booking flow can't distinguish sold-out from price-changed from session-expired. introduce one error taxonomy, map each supplier's failures onto it, and keep the retry behaviour of each client exactly as it is today the retry counts and delays per client are deliberate, so keep them exactly as they are.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "we should store the offer token's supplier and expiry rather than inferring them, and the API needs to return a clear 410 rather than a generic error. decide the shape with me, then build it", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "poller reports interfaces down that are demonstrably up, intermittently:\n\n2026-07-29T11:02:14Z WARN snmp: timeout polling 10.44.2.71 oid=1.3.6.1.2.1.2.2.1.8 (ifOperStatus) attempt=1\n2026-07-29T11:02:19Z WARN snmp: timeout polling 10.44.2.71 oid=1.3.6.1.2.1.2.2.1.8 attempt=2\n2026-07-29T11:02:24Z ERROR snmp: giving up on 10.44.2.71, marking 48 interfaces down\n2026-07-29T11:02:25Z INFO alert: DeviceDown fired for core-sw-04 (48 interfaces)\n2026-07-29T11:02:41Z INFO snmp: poll of 10.44.2.71 succeeded in 182ms\n2026-07-29T11:02:41Z INFO alert: DeviceDown resolved for core-sw-04\n\nthis device has 480 interfaces, we poll it every 30 seconds, and the timeouts cluster at the top of the minute", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "extension icon needs to be 128px", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "seat map assumes a 3-4-3 layout for wide bodies, which is why business class renders ten seats across on one aircraft type. rebuild it to derive the layout entirely from the payload's seat letters, keep the existing states and interactions, and make sure it still handles the narrow bodies that make up most of our traffic narrow bodies are about eighty percent of our traffic, so they must not regress at all.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "supplier spec for the fourth integration, we build against this:\n\nPOST /partner/v2/reservations\n auth: mutual TLS plus a signed JWT, 60 second expiry, our clock must be within 5 seconds of theirs\n body: { offer_token, passengers[], contact, payment: { method: \"agency_deposit\" }, hold_minutes }\n hold_minutes: 15, 30 or 60; anything else is rejected\n response 201: { reservation_id, expires_at, price: { amount, currency }, ticketing_deadline }\n response 409: the offer token is stale — they expect us to re-search rather than retry\n response 422: passenger data rejected, with a field-level error list\n reservations not ticketed by expires_at are released automatically and we are not charged\n ticketing is a separate call and is irreversible; there is no cancel endpoint, only a refund workflow by email", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "the interface detail panel should overlay a 24h traffic chart with errors and discards on one axis", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "our health endpoint reports healthy while celery has no consumers at all", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "extension's package.json versus what the marketplace wants:\n\n{\n \"name\": \"navigator\",\n \"publisher\": \"lumen\",\n \"version\": \"1.4.2\",\n \"engines\": { \"vscode\": \"^1.74.0\" },\n \"activationEvents\": [\"*\"],\n \"categories\": [\"Other\"],\n \"repository\": \"[email protected]:lumen/navigator.git\",\n \"icon\": \"images/icon.png\"\n}\n\nmarketplace warnings on publish:\n WARNING Using '*' activation is deprecated and will hurt startup performance\n WARNING Repository URL should be an https URL\n WARNING Icon should be at least 128x128 (found 96x96)\n WARNING A README.md with content is recommended", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "pasted-context", "lang": "en"}
{"prompt": "a colleague added useMemo and useCallback to the results list, but the filters object is built inline in the parent and onSelect is an inline arrow, so i suspect nothing is actually memoised. rather than argue in the PR, work out what the render behaviour really is with two hundred results and tell me whether the change helps, hurts, or does nothing two hundred results is the normal case and a thousand is our worst.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "supplier integration guide was written for amadeus and never updated, while sabre has no hold concept and the direct airline can't tell us cancellation fees in advance. rewrite it to cover all three honestly, structured so the engineer adding the fourth can see which behaviours are supplier-specific and which our code assumes are universal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "extension, startup", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "seat map needs to handle premium cabins properly and the same work should give us keyboard selection, which the audit flagged. do the layout fix first, then the accessibility pass, and tell me if the two conflict anywhere", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "our staging poller polls twelve devices and prod polls fourteen hundred, with the same timeout", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "the symbol tree should show a progress node while indexing instead of appearing empty", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "booking funnel fails seven accessibility items and our largest partner commissioned the audit, so the fixes need to be real. work through them, and produce the summary we send back to the partner describing what changed", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "celery workers stop consuming after a few hours and all four are sitting in retry backoff with prefetch set to four, which looks like the whole story but i'd like it confirmed. diagnose it properly, then change whatever configuration or code prevents a slow supplier from parking the entire pool", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "what guarantees does the poller make about interface counters after a device reboots", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "is the offer dedupe in the search view actually removing duplicates, or just adjacent ones", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "extension's settings are documented only by their JSON schema descriptions, which don't mention that excludeGlobs are relative to the workspace root, that exceeding the size limit silently triggers a minutes-long rebuild, or that provider order explains why go-to-definition sometimes lands in a type declaration file. write the settings reference that covers the behaviour rather than the types assume the reader is a developer who has already installed it and is puzzled.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "a walkthrough of the booking state transitions would help before i touch the cancellation flow", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "vscode's output channel for our extension on a windows machine, works fine on mac:\n\n[lumen.navigator] activating\n[lumen.navigator] workspace root: c:\\Users\\dana\\src\\Platform\n[lumen.navigator] index path: c:\\Users\\dana\\src\\Platform/.lumen/index.json\n[lumen.navigator] ENOENT: no such file or directory, open 'c:\\Users\\dana\\src\\Platform/.lumen/index.json'\n[lumen.navigator] creating index...\n[lumen.navigator] resolved 0 symbols from 41,882 files\n[lumen.navigator] go-to-definition returned no results for 'BookingService'\n[lumen.navigator] pattern used: c:\\Users\\dana\\src\\Platform/**/*.ts\n\nsomething is mixing separators and i'm not sure which layer is at fault", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "les prix affichés changent entre la recherche et le paiement pour environ 2% des réservations :\n\nrecherche vol=LH1234 date=2026-09-12 prix=214.00 EUR devise_source=EUR cache=HIT age=118s\npanier vol=LH1234 date=2026-09-12 prix=214.00 EUR verrouillé_à=11:02:14\npaiement vol=LH1234 date=2026-09-12 prix=228.50 EUR source=fournisseur cache=MISS\nerreur PriceChangedError levée, l'utilisateur voit « le prix a changé »\n\nle verrou de prix est censé durer 15 minutes, l'écart apparaît surtout entre 11h et 13h, et le fournisseur nous facture chaque appel de vérification", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "fr"}
{"prompt": "grafana shows the collector dropping metrics and the go runtime numbers look off:\n\ngo_goroutines{job=\"collector\"} 41,882\ngo_memstats_heap_inuse_bytes{job=\"collector\"} 6.1e+09\ngo_memstats_heap_objects{job=\"collector\"} 82,441,102\ngo_gc_duration_seconds{quantile=\"0.99\"} 2.41\ngo_sched_latencies_seconds{quantile=\"0.99\"} 0.88\nprocess_cpu_seconds_total rate 3.8 cores\nprocess_open_fds{job=\"collector\"} 38,112\ncollector_samples_dropped_total rate 1,204/s\ncollector_scrape_duration_seconds{quantile=\"0.5\"} 11.2\ncollector_scrape_duration_seconds{quantile=\"0.9\"} 28.4\ncollector_poll_errors_total rate 88/s\n\ndeployment: 1 replica, 8 vCPU, 8 GiB limit, restarts 3 times in the last day\nscrape interval 30s, 1,400 devices, each device poll spawns a goroutine per OID group, and every group dials its own SNMP session\n\nthe drops started when we onboarded the last 400 devices, and nothing in the collector's own config changed", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "polling loop that everything else hangs off. is the concurrency model defensible?\n\nfunc (c *Collector) Run(ctx context.Context) {\n\tticker := time.NewTicker(c.interval)\n\tfor {\n\t\tselect {\n\t\tcase <-ctx.Done():\n\t\t\treturn\n\t\tcase <-ticker.C:\n\t\t\tfor _, dev := range c.devices {\n\t\t\t\tgo func(d Device) {\n\t\t\t\t\tfor _, group := range d.OIDGroups {\n\t\t\t\t\t\tgo c.pollGroup(ctx, d, group)\n\t\t\t\t\t}\n\t\t\t\t}(dev)\n\t\t\t}\n\t\t}\n\t}\n}\n\n1,400 devices, 6 to 40 OID groups each, 30 second interval, and pollGroup has a 25 second timeout", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the price-change complaints, they need to become a customer-facing explanation:\n\n- price shown in search can be up to 5 minutes stale because we cache supplier responses\n- adding to cart locks our price for 15 minutes, but does not reserve anything with the airline\n- at payment we re-check with the airline, and if their price moved more than 1% the booking fails\n- this happens most often on the busiest routes at midday\n- the customer sees \"the price has changed\" and has to search again, losing their seat selection\n- we do not currently show the new price, which is the single most common complaint\n\nwrite the help centre article, and be honest without making us sound careless", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from last night's alert storm. the write-up is due at noon:\n\n23:41 first DeviceDown page for core-sw-04\n23:41 to 00:12 — 38 more DeviceDown pages across 14 devices\n00:14 on-call silences the DeviceDown rule entirely\n00:20 discovers all devices are reachable by hand\n00:44 collector restarted, alerts clear\n01:02 alerts return, on-call silences again and goes back to bed\n08:30 root cause found: a firmware upgrade on the aggregation switch changed the SNMP response size, our poller's buffer is 8KB and the response is now 9KB\n09:15 buffer raised to 64KB, deployed, no recurrence\n\nthe honest bit is that we silenced a page rather than investigating, twice, and the rule had cried wolf for months", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "die Notizen aus dem Architektur-Meeting, daraus soll ein Entscheidungsdokument werden:\n\n- der Suchdienst cached Angebote 300 Sekunden, das ist historisch gewachsen und niemand weiß, warum genau 300\n- die Preisgarantie von 15 Minuten ist ein Marketing-Versprechen ohne technische Entsprechung\n- ein echter Bestand-Hold beim Anbieter kostet Geld pro Anfrage, etwa 0,02 €\n- bei 40.000 Suchen täglich und 3% Konversion wären das rund 24 € pro Tag für echte Holds\n- Alternative: den Preis auf eigene Kosten garantieren und die Differenz selbst tragen\n- Finanzen hat noch keine Zahlen dazu gesehen\n\nschreib das als Entscheidungsvorlage mit Optionen und einer Empfehlung", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "de"}
{"prompt": "我们的公开 API 只有一份过时的 postman collection，需要写一份正式文档。这是搜索接口目前的行为：\n\nGET /v1/search\n 参数：origin、destination（IATA 三字码，必填）、date（YYYY-MM-DD，必填）、return_date（可选）、\n cabin（economy|premium|business|first，默认 economy）、passengers（默认 1，最多 9）、\n currency（默认按 IP 判断，可覆盖）、max_stops（可选）\n 返回：offers 数组，按价格升序；每个 offer 含 offer_id、price、currency、segments、fare_rules_url\n offer_id 有效期 300 秒，过期后加入购物车会返回 410\n 同一组参数在 300 秒内返回缓存结果，响应头 X-Cache 标记 HIT/MISS\n 错误：400 参数无效、404 无航线、429 超限（每分钟 60 次）、502 供应商不可用\n 注意：passengers 超过 6 时部分供应商会拒绝，我们会静默降级为返回更少的 offers\n\n请写成对外的接口文档，特别把 300 秒有效期和静默降级说清楚", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "zh"}
{"prompt": "ruff and mypy on the bookings package, and the gate goes on friday:\n\nbookings/services/confirm.py:88: error: Item \"None\" of \"Optional[Hold]\" has no attribute \"id\" [union-attr]\nbookings/services/confirm.py:141: error: Argument 1 to \"retrieve\" has incompatible type \"Optional[str]\"; expected \"str\" [arg-type]\nbookings/tasks.py:22: error: Function is missing a return type annotation [no-untyped-def]\nbookings/models.py:212: error: Incompatible types in assignment (expression has type \"str\", variable has type \"Decimal\") [assignment]\nsuppliers/sabre/client.py:41: note: By default the bodies of untyped functions are not checked\n\nFound 4 errors in 4 files (checked 212 source files)\n\nthe models.py one looks like an actual bug rather than a typing complaint", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "prod and staging poller config, and staging has never reproduced a single timeout:\n\n# staging/snmp.yaml\nsnmp:\n timeout: 10s\n retries: 3\n max_repetitions: 10\n buffer_bytes: 65536\n per_device_concurrency: 4\n session_reuse: true\n interval: 60s\n devices: 12\n\n# prod/snmp.yaml\nsnmp:\n timeout: 5s\n retries: 2\n max_repetitions: 50\n buffer_bytes: 8192\n per_device_concurrency: 0 # unlimited\n session_reuse: false\n interval: 30s\n devices: 1400\n\n# what prod looks like at the top of a minute\n snmp_timeouts_total rate 41/s\n snmp_response_bytes p99 9,214\n goroutines 41,882\n\nthe aggregation switches were upgraded last month and their responses grew; staging's switches are two firmware versions behind", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "eslint on the react app after we turned on the exhaustive-deps rule:\n\nsrc/search/ResultsList.tsx\n 22:6 warning React Hook useMemo has a missing dependency: 'onSelect' react-hooks/exhaustive-deps\n 41:11 warning The 'filters' object makes the dependencies of useMemo change on every render react-hooks/exhaustive-deps\n\nsrc/booking/SeatMap.tsx\n 88:5 warning React Hook useEffect has a missing dependency: 'flightId' react-hooks/exhaustive-deps\n 112:9 error React Hook \"useSeatAvailability\" is called conditionally react-hooks/rules-of-hooks\n\nsrc/checkout/PriceSummary.tsx\n 19:3 warning React Hook useCallback received a function whose dependencies are unknown\n\n✖ 5 problems (1 error, 4 warnings)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "this view has accumulated every requirement we've had for two years. same responses, better structure:\n\ndef search(request):\n q = parse_query(request.GET)\n if q.passengers > 6 and not request.user.is_staff:\n q.passengers = 6 # silent downgrade, product asked for this\n key = cache_key(q)\n if cached := cache.get(key):\n offers = cached\n else:\n offers = []\n for name, supplier in SUPPLIERS.items():\n if name == \"sabre\" and q.cabin == \"first\":\n continue # sabre first class is unreliable\n try:\n offers += supplier.search(q)\n except SupplierError:\n logger.warning(\"supplier %s failed\", name)\n offers = dedupe(sorted(offers, key=lambda o: o.price))\n cache.set(key, offers, 300)\n if request.GET.get(\"max_stops\"):\n offers = [o for o in offers if o.stops <= int(request.GET[\"max_stops\"])]\n return Response(OfferSerializer(offers, many=True).data)", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "nuestro código de reintentos está copiado en cinco sitios con parámetros distintos:\n\n# bookings/tasks.py\[email protected](bind=True, max_retries=5, default_retry_delay=60)\n\n# suppliers/amadeus/client.py\nfor attempt in range(3):\n try: return self._call(...)\n except Timeout: time.sleep(2 ** attempt)\n\n# suppliers/sabre/client.py\n@retry(stop=stop_after_attempt(4), wait=wait_exponential(multiplier=1, max=30))\n\n# payments/gateway.py\nwhile tries < 3:\n ...\n tries += 1\n\n# notifications/email.py\[email protected](bind=True, max_retries=10, default_retry_delay=300)\n\nquiero una sola política, configurable por integración, sin cambiar el comportamiento actual de cada una", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "es"}
{"prompt": "react components each fetch their own data and it shows on the results page:\n\nResultsPage\n ├─ FiltersPanel → GET /v1/filters?query=…\n ├─ ResultsList → GET /v1/search?…\n │ └─ ResultRow ×200 → GET /v1/airlines/{code} (one per row, cached in a module-level map)\n ├─ PriceHistogram → GET /v1/search?… (same call as ResultsList, different component)\n └─ RecommendedBadge → GET /v1/recommendations?…\n\nthe airline lookups are the same twelve airlines repeated, and the search call fires twice on every filter change", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "quarter planning input, and i owe a sequenced plan by friday:\n\n- a fourth supplier integration is contractually due in november\n- the price-change failure is our top conversion loss and product wants it fixed \"properly\"\n- the collector's alerting is so noisy that on-call has stopped reading it\n- the vscode extension has 40,000 installs and a one-star review problem about startup time\n- we're one engineer down until october and the person leaving owns the supplier layer\n- there's a compliance requirement to store PNR data in-region for EU bookings from january\n- the search cache is 300 seconds because someone typed 300 in 2022", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, i want the thinking before anyone starts:\n\nTRV-410 — Real inventory holds\nToday the fifteen-minute price guarantee is a local database row with no supplier-side reservation, which is why 2% of bookings fail at payment with a price change. The proposal is to take a real hold with the supplier when a user reaches checkout. Costs: about €0.02 per hold, roughly 1,200 checkouts a day. Complications: only two of our three suppliers support holds; hold durations differ (20 vs 60 minutes); a held seat that isn't paid for must be released or we're charged; and our checkout has no concept of an expiring reservation in the UI.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "compliance requirement landed with no technical detail, which means the plan is on us:\n\n\"From 1 January, passenger name record data for bookings originating in the EU must be stored and processed within the EU. This includes backups, search indexes and any derived analytics. Access from outside the EU is permitted for support purposes only, must be logged, and must be justifiable per access. Suppliers acting as processors must be listed with their locations.\"\n\nwe run in one US region, our search index is a managed service in the same region, analytics goes to a US warehouse, and two of our three suppliers process in the US. i want the options and an honest cost per option", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the seat map, react, replacing the one that can't handle premium cabins:\n\nSeat map\n- Cabin sections stacked vertically with a sticky class label; layout comes from the payload, never assumed.\n- Seats 32px square, 4px gaps, aisles rendered as 24px gaps derived from the seat letter sequence.\n- States: available (outline), selected (filled accent), occupied (filled muted, not clickable), blocked (diagonal hatch), extra-legroom (small badge).\n- Exit rows get a subtle marker on the row number and a tooltip explaining the restrictions.\n- Selecting a seat with a fee opens an inline confirmation with the price before committing.\n- Hovering shows seat number, features and price; keyboard focus shows the same in a live region.\n- Below 480px the map scrolls horizontally with the row numbers pinned to the left.\n- Availability arrives over a websocket and seats must update without losing the user's current selection.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "handoff for the extension's tree view, build it against the vscode API:\n\nSymbol explorer (tree view in the sidebar)\n- Root nodes are the workspace folders; children are files with symbols, lazily loaded on expand.\n- Symbol icons follow the built-in ThemeIcon set so they match the user's icon theme.\n- Selecting a symbol reveals it in the editor without stealing focus; double-click focuses the editor.\n- A filter box at the top of the view, debounced 150ms, matching on fuzzy symbol name, showing match counts per file.\n- While indexing, show a progress item at the root rather than an empty tree.\n- If the index is stale, show a warning node with a \"Reindex\" inline action.\n- Respect the user's `lumen.excludeGlobs` and never show files excluded by the workspace's files.exclude.\n- The whole view must be usable when the index is missing entirely — degrade to on-demand parsing of the open file.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings for the booking funnel, from an audit our largest partner commissioned:\n\n1. The date picker is unusable with a keyboard; arrow keys move the page, not the focused date.\n2. Seat selection conveys availability with colour alone, and the seat buttons have no accessible names.\n3. Errors on the passenger form appear above the form but focus stays where it was, so they are never announced.\n4. The price breakdown is a table with no headers, read as a stream of numbers.\n5. The countdown timer on checkout is announced by screen readers every second.\n6. The \"continue\" button is disabled until the form validates, with no explanation of what's missing.\n7. Contrast on the muted price text is 3.4:1.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "dashboard spec from the network team, they live in this screen during an incident:\n\nDevice overview\n- Left: device tree by site then role, with a status dot per node that rolls up the worst child state.\n- Main: interface table — name, admin/oper status, utilisation in and out as inline bars, errors, last change. Sortable, 50 rows a page, sticky header.\n- Utilisation bars use a fixed scale to 100% of interface speed, with a marker at the alert threshold.\n- Selecting an interface opens a 24h detail panel with traffic, errors and discards on one time axis.\n- Down interfaces sort to the top by default but the sort must be overridable and remembered.\n- Polling status is visible: last successful poll per device, and a clear indicator when data is stale rather than showing old numbers as current.\n- The whole page has to work on a 1366x768 laptop in a datacentre, which is what the field engineers carry.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for in-region PNR storage, needs implementing:\n\nCREATE TABLE pnr_records (\n id uuid PRIMARY KEY,\n booking_id uuid NOT NULL REFERENCES bookings(id),\n region text NOT NULL CHECK (region IN ('eu','us')),\n record_locator text NOT NULL,\n payload_enc bytea NOT NULL,\n key_id text NOT NULL,\n created_at timestamptz NOT NULL DEFAULT now(),\n purge_after timestamptz NOT NULL\n);\n\nEU rows must live in the EU database only; the US service may reference them by id but must never read payload_enc; support access has to be logged with a reason; and the purge job must run in-region and be provable to an auditor", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "requests advisory bump, please", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "confirmation email has the old support address", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "el selector de moneda ignora la del usuario", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "es"}
{"prompt": "DeviceDown needs two consecutive failures", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "drop the wildcard activation event", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "playwright retries to 2 on CI", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "Sitzungsdauer in Staging auf 14 Tage", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "de"}
{"prompt": "trace on for failed playwright runs", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "aisle gaps from the seat letters", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "sticky cabin labels on the seat map", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "extension has forty thousand installs and a one-star review problem about startup time, which activation events and a synchronous index build explain entirely. before rewriting the indexer i want a view on the right architecture — lazy activation, background indexing, incremental updates, and where the index should live — and an idea of what we can ship in a week versus what needs a month", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "seat availability websocket reconnects without resubscribing, so the map goes stale silently", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "supplier protocol declares five methods that all three implementations satisfy on paper, while in practice one of them fakes holds locally and another can't report cancellation fees. read the interface against the three clients and tell me where the abstraction is lying, and which of those lies has actually cost us money i want the list ordered by what it has actually cost us, not by how ugly it looks.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "the spec for the availability websocket, which we now have to implement server-side:\n\nWS /v1/flights/{id}/availability\n auth: the same bearer token as the REST API, passed as a subprotocol; anonymous sessions get a short-lived token from /v1/sessions\n on connect: server sends a full snapshot { seats: { \"12A\": \"available\", \"12B\": \"held\", ... }, version }\n thereafter: deltas only, { changes: { \"12A\": \"held\" }, version } where version increments by one\n a client that sees a version gap must resubscribe rather than guess; the server must tolerate that at any rate\n heartbeat: server ping every 20s, client must respond within 10s or be dropped\n a seat held by this session is reported as \"mine\" rather than \"held\"\n peak: about 4,000 concurrent sessions per popular flight in the hour before departure, and roughly 40 changes per second on those\n the snapshot must be servable from cache; only deltas need to be per-flight ordered", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "our seat holds expire via a beat task every minute, and i suspect that's the wrong mechanism entirely", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "filter box in the symbol tree", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "utilisation bars on the interface table", "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": "countdown announces every second", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "date picker ignores arrow keys", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "stale poll data looks current", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "muted price text fails contrast", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "`RelativePattern` everywhere in the extension", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "pull the filters out of the search view", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "split Device by SNMP version", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "une seule couche de cache, pas trois", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "fr"}
{"prompt": "`record_locator` naming, be consistent", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "lift the airline lookup into one query", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "inline `cache_key`, single caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "docstrings on the supplier protocol", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "changelog for collector 3.2", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota sobre o bloqueio de preço, para o suporte", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "pt"}
{"prompt": "document the offer token expiry", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the hold design for the team", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the buffer fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "¿por qué el poller marca 48 interfaces caídas?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "es"}
{"prompt": "can the index rebuild block activation?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the refund path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "go-to-definition finds nothing on windows", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "double refunds on slow cancellations", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "warum meldet der Collector Geräte als down?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for per-device poll status", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "push on with it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "less noisy", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "you decide what's next", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo del cache, otra vez", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "es"}
{"prompt": "tidy that up", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "same as the other one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "whatever helps on-call most", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "one last pass", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "keep it moving", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "any of them, your call", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "try something better", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "real inventory holds are the fix for our biggest conversion loss, but only two of our three suppliers support them, the durations differ, an unpaid hold has to be released or we get charged, and our checkout UI has no concept of an expiring reservation at all. i'd like the whole thing thought through — including whether we hold on entering checkout or on reaching payment — before anyone writes a line of it, because the wrong choice here costs money per booking rather than per deploy", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "EU data residency requirement lands in january and today we run in one US region, with a managed search index in the same region, analytics in a US warehouse, and two of three suppliers processing in the US. before we promise anything to legal i need the realistic options laid out, including the one where we tell them we can't do it by january, with the cost and the risk of each written plainly", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "fourth supplier integration is contractually due in november and the engineer who owns the supplier layer leaves in three weeks. i'd like a plan that treats that as the main constraint: what has to be documented before they go, what the integration actually requires given their reservation model is unlike the other three, and where we should deliberately do the dumb thing to hit the date", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "nobody can tell me whether our seat hold is genuinely exclusive: it takes a row lock on the booking rather than the seat, checks for an existing hold, and also writes a cache key that a separate expiry task deletes. work through what two concurrent requests for the same seat actually do, including the case where the expiry task fires between the check and the insert", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "alerting rules we inherited page on any interface error rate above zero and on device unreachability with no delay, which is most of our forty nightly pages. go through each rule and tell me what it would fire on in a healthy network, so i can take an evidence-based proposal to the team rather than an opinion assume i have to defend the proposal to a network engineer who wrote the originals.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "search view has accumulated two years of requirements inline — a silent passenger downgrade, a supplier skipped for one cabin class, caching, filtering after the cache read — and it's now impossible to change safely. restructure it so each of those is a named, testable piece, with identical responses for every query in last week's access log last week's access log is in the analytics bucket if you want real queries to compare against.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "device struct has fields that only apply to one SNMP version, a vendor quirks map read by string key in six places, and polling state mixed in with configuration. separate configuration from runtime state and make the version-specific fields impossible to set wrongly, without changing how any existing device config file is parsed every customer's config file must parse unchanged, including the ones with unknown keys.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "results page fires the same search request from two components, looks up the same twelve airlines two hundred times, and caches them in a module-level map that never invalidates. consolidate the data fetching without changing what renders, and make the airline lookup a single request rather than a hidden N+1 the twelve airlines are effectively static, so a single request at page load is fine.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "bookings fail at payment for about two percent of users with a price change, and the pattern is midday on busy routes, but i can't tell from the code whether that's genuine airline price movement or our own cache going stale between search and checkout. work it through end to end before we start proposing fixes i'd like the diagnosis before any proposal, including how we'd measure whether a fix worked.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "network dashboard shows stale poll data as though it were current, which during an incident is actively dangerous. surface the last successful poll per device, mark stale rows unmistakably, and keep the table usable on the 1366x768 laptops the field engineers actually carry the field engineers are the ones who will tell us if it's still unusable, so keep it dense.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "before the fourth supplier integration starts i want the reservation model designed properly — holds, ticketing deadlines, what we do when a supplier has no cancel endpoint — and then the reservation state machine implemented against it, so the integration itself is mostly mapping their sandbox is available now, so anything we can validate early is worth doing early.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "collector needs to scale to ten thousand devices and the first honest step is admitting the current concurrency model can't. design the target — pools, sharding, backpressure — then implement the per-device concurrency limit so tonight's pages stop while the bigger work happens on-premise customers upgrade by copying a binary, which constrains what the design can assume.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "data residency needs a plan and also needs something started, because january is not far away. give me the options for EU PNR storage with costs, then set up the region-tagged storage layer so the rest can follow whichever option we pick legal wants the options in writing before they'll commit to a date with the regulator.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "das Alerting ist unbrauchbar und niemand liest es mehr. Ich hätte gern zuerst ein Konzept, welche Alarme überhaupt einen Pager rechtfertigen, und danach die Umsetzung für die beiden lautesten Regeln, damit die Nacht ruhiger wird", "purpose": "planning", "secondary": "quickFix", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "de"}
{"prompt": "extension's startup problem needs an architecture, not a patch, but we also can't ship nothing for a month. plan the lazy-activation and background-indexing design, then do the activation events change so the next release is at least not catastrophic forty thousand installs means a bad release is visible in the reviews within a day.", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "price-lock behaviour needs documenting for support and, while writing it, i expect you'll find that the fifteen minutes doesn't mean what marketing thinks. produce the article, and separately tell me every claim on our pricing page that the code doesn't support support answers this several times a day and every answer is slightly different.", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "public search API is documented by a stale postman collection. write the proper reference, and confirm from the code whether the silent downgrade above six passengers still happens, because if it does it needs to be in the docs rather than a surprise two partners integrate against it and both have asked for a real reference this quarter.", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la guía de integración para el cuarto proveedor y, de paso, comprueba si nuestra interfaz de supplier soporta su modelo de reservas o si vamos a necesitar cambiarla", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "on-call handbook has to exist before our supplier-layer owner leaves. write it from what the team does today, and add the two runbook entries for the failures they're the only one who knows how to fix they have three weeks left and are already half-committed to handover meetings.", "purpose": "writing", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "retry logic is copied into five places with different limits and delays. unify it behind one configurable policy, keeping each integration's current effective behaviour, and then document which integration uses which settings and why none of these can change behaviour without finance noticing, so keep the effective numbers identical.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "extension builds file globs three different ways and two of them are broken on windows. standardise on the API's own pattern type, and add the note to the contributing guide about why string concatenation of paths is not acceptable here roughly a third of our installs are on windows, which is where this actually matters.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "django settings differ across environments in ways nobody tracks, and the session backend difference is probably why production logs people out mid-booking. rationalise the settings layering, and confirm whether the cache eviction is what's killing sessions before you change anything production is the only environment with the cache-backed sessions, which is suspicious on its own.", "purpose": "refactor", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "supplier abstraction hides real differences behind a uniform interface. restructure it so the differences are explicit in the types, and while you're in there tell me which of the three clients would break if we added a timeout shorter than their slowest observed response the fourth supplier lands in november and will make this worse if we don't move first.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "refunds are occasionally issued twice when the supplier answers slowly, and the retry has no idempotency key. find out exactly how the duplicate arises, then make the refund path idempotent end to end — including the case where our own webhook arrives before the original call returns finance has caught three of these this quarter and would like to stop being the detection mechanism.", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "e2e suite flakes one run in four on the seat step because availability arrives over a websocket that's instant locally. work out whether that's the only cause, then fix the tests so they wait on the right condition rather than on time", "purpose": "debugging", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "dependabot batch has one advisory and three minors, one of which changes namespace handling in the library our SOAP client depends on. work out which are safe, apply those, and note what testing the xmltodict one would need", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt": "snmp buffer is 8KB in production and 64KB in staging, which is the whole incident. change it, and check whether any other tuning parameter differs between the two in a way that would hide a production failure", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.4, "slice": "mixed", "lang": "en"}
{"prompt": "booking model has a `status` string with eleven values and no state machine, and three of them are only ever set by a script", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "celery tasks catch bare exceptions and log them, so a supplier failure and a bug in our code look identical in the logs", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "rename the collector's `Device.Community` field, it's meaningless for the v3 devices that are now the majority", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain how a supplier session expiry surfaces to the user, and why it takes ten minutes to appear", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "why does the collector re-dial SNMP sessions for every OID group rather than reusing one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "someone should check whether our refund endpoint can be called twice by a double-click", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that search results are cached across users including their currency and loyalty tier", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment le verrou de prix interagit avec le cache de recherche ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/suppliers.md describes a hold API that only one of our three suppliers actually has", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "a short note for the team explaining why the search cache TTL is changing, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "社内向けに、予約が失敗したときの調査手順をまとめてください", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "ja"}
{"prompt": "collector's config reference documents six options and the binary reads nineteen", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "write the marketplace description for the extension, the current one is three sentences from 2023", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "precisamos de uma página que explique aos clientes o que acontece quando o preço muda no pagamento", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "pt"}
{"prompt": "price on the confirmation email is formatted with the server's locale rather than the customer's", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "how should we handle suppliers that can't tell us a cancellation fee until after ticketing", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test the booking flow against three suppliers without hitting their sandboxes constantly", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether the extension's index belongs on disk, in memory, or in a language server", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "we need a story for on-premise collector upgrades, customers currently copy a binary and hope", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "what should our approach be to gNMI streaming telemetry, given the newer devices expect it and we only speak SNMP", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "three suppliers, three rate limits, one of them unpublished and enforced by disconnection — how should we shape our outbound traffic", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns a booking's full timeline — searched, held, paid, ticketed, cancelled — for support", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "seat holds should release automatically when the payment session expires, rather than fifteen minutes later", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "per-device polling intervals, so the noisy core switches can be polled less often than the edge", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "passenger form errors should move focus to the first invalid field and announce the summary", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "whichever of those is quickest", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "finish the supplier bit", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "i'd like an honest read of whether our booking status field is a state machine or just a string that eleven things write to, and if it's the latter, the transitions modelled properly with the three script-only values either legitimised or removed", "purpose": "review", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "our celery error handling catches bare exceptions everywhere, so a supplier timeout and a genuine bug in our code produce identical log lines. separate them properly, and tell me how many of last week's \"supplier failures\" were actually our own errors in disguise", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "the booking timeline endpoint support keeps asking for needs designing before it's built — what events we record, how far back, whether it reads from the audit log or its own table. decide that with me, then implement it", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt":"Staging: Incident timeline — INC-47119\n\n08:02 deploy GossamerDriftConsoleFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the GossamerDriftConsoleFlow 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":"Ticket OPS-47132: retire the legacy replay path for GossamerWrenExportFlow\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 GossamerWrenExportFlow 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 deliverables are holding up GossamerBirchMigratorCoordinator. First, lay out a staged migration for GossamerBirchMigratorCoordinator. In the same workstream, also add the visible loading and offline states. The relevant starting point is projects/gossamer/web/components/FilterDrawer.vue, which follows Room conventions and currently suffers from lease renewal code copied across three workers. Keep voiceover and keyboard navigation working.\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":"Move GossamerEmberRelayService behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Milestones for replacing GossamerBeaconStoreStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"GossamerOspreyJobService 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- keep VoiceOver and keyboard navigation working\n- retain the current OpenTelemetry operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka 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":"GossamerAsterWebhookCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"On compact widths, GossamerRainfallDBService's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Bring GossamerAsterWebhookStore'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":"// projects/gossamer/web/components/FilterDrawer.vue\nfinal class GossamerMarbleTokenFlowCoordinator {\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 GossamerMarbleTokenFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Read projects/gossamer/Sources/App/SessionStore.swift and tell me whether GossamerPineMetricsStore can acknowledge work before its durable write completes; this is a read-only safety pass. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"GossamerQuartzPlayerService 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":"GossamerCraneWorkspaceCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"CI: Ticket OPS-47154: retire the legacy replay path for GossamerDeltaCanvasCoordinator\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 GossamerDeltaCanvasCoordinator 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":"// projects/gossamer/services/ledger/replay.go\nfinal class GossamerSableParserCoordinatorCoordinator {\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 を維持し、根拠と判断を明確にしてください。 Restructure GossamerSableParserCoordinator 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":"Atlas: projects/gossamer/cmd/exporter/main.py 里的 GossamerFrostPanelService 最近在 gRPC 流程中出现间歇性问题。 请阅读现有流程，判断 ownership、取消和顺序是否安全，只需要分析。\n\n约束：\n- 继续使用 gRPC\n- 保持兼容性和取消语义\n- 改动只限于 GossamerFrostPanelService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"zh"}
{"prompt":"GossamerMarbleTokenCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Beacon: # projects/gossamer/Sources/App/SessionStore.swift\n[worker.gossamernovapickercoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamernovapickercoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamernovapickercoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerNovaPickerCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47150\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/gossamer/Sources/App/SessionStore.swift and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Cinder: Incident timeline — INC-47129\n\n08:02 deploy GossamerOrbitSyncFlow 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À partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Turn the material above into a concise GossamerOrbitSyncFlow 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":"Delta: // projects/gossamer/cmd/exporter/main.py\nfinal class GossamerBasilRunnerFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate GossamerBasilRunnerFlow'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":"GossamerPrismCacheFlow needs an idempotent replay endpoint backed by Swift 6; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"GossamerSlateEditorService occasionally exhibits duplicate retries after a network handoff, but only after a reconnect. Follow the data and cancellation paths in projects/gossamer/src/sync/reconcile.ts and identify the cause before changing anything.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Could GossamerDeltaCanvasFlow show the active FastAPI 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":"Does GossamerCloudReconcilerService 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":"Test Suite 'GossamerBeaconStoreFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[GossamerBeaconStoreFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/gossamer/Sources/App/SessionStore.swift:144: error: -[GossamerBeaconStoreFlowTests 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 '-[GossamerBeaconStoreFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nReconstruct the GossamerBeaconStoreFlow 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":"Does GossamerLedgerGateStore enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Draft GossamerBeaconStoreService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Ember: The data is already available in projects/gossamer/Sources/CLI/Commands/Doctor.swift; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current GossamerGarnetModalService design actually guarantees what its callers assume. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside GossamerGarnetModalService\n- keep VoiceOver and keyboard navigation working\n\nThe relevant code crosses healthcare, Svelte, Kafka. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Could GossamerLedgerGateService show the active Room sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Frost: projects/gossamer/services/ledger/replay.go 里的 GossamerHarborIndexStore 最近在 Room 流程中出现间歇性问题。 请给出阶段、兼容层、指标、rollback 和 ownership，先不要修改代码。\n\n约束：\n- 继续使用 Room\n- 保持兼容性和取消语义\n- 改动只限于 GossamerHarborIndexStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"zh"}
{"prompt":"Incident timeline — INC-47139\n\n08:02 deploy GossamerJuniperCLIFlow 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 GossamerJuniperCLIFlow, 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":"Garnet: Ticket OPS-47124: retire the legacy replay path for GossamerSummitProxyFlow\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 GossamerSummitProxyFlow 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":"How does GossamerCraneWorkspaceStore propagate cancellation through the Swift 6 boundary, and are there code paths where ownership becomes ambiguous? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"On compact widths, GossamerCloudReconcilerStore'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.6,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter GossamerIrisBatchFlow\n RUN v3.2.4 /workspace/apps/console\n × GossamerIrisBatchFlow > 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=47127 phase=resume storedCursor=seg-0183\n session=47127 phase=fetch requestCursor=seg-0183 pageSize=200\n session=47127 phase=commit receivedCursor=seg-0184 itemCount=0\n session=47127 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the GossamerIrisBatchFlow 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":"GossamerLedgerGateCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"One contained cleanup in projects/gossamer/web/components/FilterDrawer.vue: remove the obsolete GossamerSableParserFlow import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"boundary","lang":"en"}
{"prompt":"For GossamerSummitProxyCoordinator, separate GossamerSummitProxyCoordinator's policy from transport without behavior changes; once that is complete, correct the known stale timeout beside it. Work from projects/gossamer/crates/index/src/segment.rs, stay with FastAPI, and keep VoiceOver and keyboard navigation working. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Harbor: # projects/gossamer/internal/auth/refresh.go\n[worker.gossameramberfilterflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossameramberfilterflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossameramberfilterflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerAmberFilterFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47128\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/gossamer/internal/auth/refresh.go. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"The next client release depends on a new GossamerNovaPickerService capability in projects/gossamer/Sources/CLI/Commands/Doctor.swift, with gRPC already chosen by the platform group. Implement the endpoint and durable cursor, enforce tenant authorization and idempotency, emit useful spans, cap work per request, and include focused tests for retries, cancellation, and malformed cursors.\n\nConstraints:\n- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing gRPC deployment\n- keep the work scoped to GossamerNovaPickerService and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a deadlock that appears only during shutdown in GossamerRainfallDBStore, 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":"Iris: The first GossamerSableParserStore request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current GossamerBasilRunnerStore design actually guarantees what its callers assume. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside GossamerBasilRunnerStore\n- keep VoiceOver and keyboard navigation working\n\nThe relevant code crosses healthcare, Svelte, Kafka. Prefer evidence from the repository and make any assumption explicit.\n\nReturn an assessment of the existing artifact; only quote enough to make the walkthrough understandable.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Assess the GossamerCoralUploadService diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Summarize the GossamerAmberFilterService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Juniper: Could GossamerTideWorkerStore show the active Room sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Kestrel: // projects/gossamer/web/components/FilterDrawer.vue\nfinal class GossamerHarborIndexFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nAdd the bounded GossamerHarborIndexFlow 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.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Lumen: // projects/gossamer/workers/thumbnail/consumer.ex\nfinal class GossamerFernSnapshotFlowCoordinator {\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\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Split GossamerFernSnapshotFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"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_47121'\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_47121'::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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Wire GossamerKiteSchedulerFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"GossamerRavenSessionFlow's staging timeout is already known to be wrong: change the single projects/gossamer/internal/auth/refresh.go value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"GossamerWillowCodecCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"GossamerCopperBridgeCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"GossamerJuniperCLICoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"The destination for GossamerRavenSessionService is broadly agreed; the missing piece is a reversible route from projects/gossamer/internal/auth/refresh.go to that target. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside GossamerRavenSessionService\n- keep VoiceOver and keyboard navigation working\n\nThe relevant code crosses healthcare, Svelte, Kafka. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Centre la modale GossamerDriftConsoleService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"fr"}
{"prompt":"diff --git a/projects/gossamer/Sources/CLI/Commands/Doctor.swift b/projects/gossamer/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/gossamer/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\nRead the artifact above as a skeptical reviewer. Is GossamerMapleQueueFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Maple: # projects/gossamer/Sources/App/SessionStore.swift\n[worker.gossamermicaprofileflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamermicaprofileflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamermicaprofileflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerMicaProfileFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47110\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/gossamer/Sources/App/SessionStore.swift. 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":"Vereinheitliche die GossamerDriftConsoleStore-Validatoren","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"de"}
{"prompt":"Translate the GossamerSummitProxyService setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/gossamer/Sources/CLI/Commands/Doctor.swift b/projects/gossamer/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/gossamer/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 GossamerPineMetricsFlow 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":"Translate the GossamerWrenExportService setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"# projects/gossamer/ui/settings/PrivacyPane.tsx\n[worker.gossamercraneworkspaceflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamercraneworkspaceflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamercraneworkspaceflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerCraneWorkspaceFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47147\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/gossamer/ui/settings/PrivacyPane.tsx and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"GossamerBasilRunnerCoordinator is blocking the next release because a query plan that changes after statistics refresh. I need two concrete outcomes from a single pass: finish GossamerBasilRunnerCoordinator's responsive empty and retry states, and capture the contract and rollback note for consumers. Use the existing gRPC conventions in projects/gossamer/ml/pipeline/features.py; keep VoiceOver and keyboard navigation working. 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":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"PM needs a concise migration note for GossamerDeltaCanvasStore, 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":"For GossamerBeaconStoreCoordinator, produce a consumer guide for GossamerBeaconStoreCoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/gossamer/Sources/CLI/Commands/Doctor.swift, stay with gRPC, and keep VoiceOver and keyboard navigation working. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Give GossamerOrbitSyncStore a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"What sequence would let GossamerNimbusFormFlow adopt Swift 6 with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Two engineers disagree about whether GossamerAsterWebhookService's cache is authoritative. Walk the reads and writes in projects/gossamer/ml/pipeline/features.py and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: GossamerLumenChartService has one known configuration mistake in projects/gossamer/lib/codec/frame.cc, 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- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to GossamerLumenChartService and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Three teams extended GossamerBirchMigratorService 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- keep VoiceOver and keyboard navigation working\n- retain the current Room operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka 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":"# projects/gossamer/cmd/exporter/main.py\n[worker.gossamerfrostpanelflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamerfrostpanelflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamerfrostpanelflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerFrostPanelFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47135\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/gossamer/cmd/exporter/main.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Fresh release brief for GossamerSpruceDaemonCoordinator:\n- primary outcome: produce a consumer guide for GossamerSpruceDaemonCoordinator\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/gossamer/pkg/cache/lease.rs\n- platform constraint: FastAPI\n- known complication: duplicate retries after a network handoff\n\nBoth results are required, but they should remain independently reviewable. Keep voiceover and keyboard navigation working; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"GossamerVelaDrawerCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"GossamerCedarPolicyCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"GossamerRainfallDBCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"En projects/gossamer/web/components/FilterDrawer.vue, GossamerSableParserService tiene un problema intermitente en el flujo de Room. Termina el layout responsive, estados vacío y retry, foco por teclado, dark mode y reduced motion.\n\nRestricciones:\n- seguir con Room\n- conservar compatibilidad y cancelación\n- limitar el cambio a GossamerSableParserService","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"es"}
{"prompt":"Why does GossamerCedarPolicyStore's OpenTelemetry worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Trace GossamerMosaicGridStore's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current GossamerPrismCacheService design actually guarantees what its callers assume. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside GossamerPrismCacheService\n- keep VoiceOver and keyboard navigation working\n\nThe relevant code crosses healthcare, Svelte, Kafka. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-47146: retire the legacy replay path for GossamerCloudReconcilerFlow\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 GossamerCloudReconcilerFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"boundary","lang":"en"}
{"prompt":"GossamerMapleQueueCoordinator: ship, then correct","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"GossamerFrostPanelCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"UI ticket DES-47145: finish the compact GossamerAsterWebhookFlow filter experience\n\nRoute: /catalog/search\nSource: projects/gossamer/ml/pipeline/features.py\nFramework: gRPC\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\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Use the UI evidence to complete GossamerAsterWebhookFlow'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":"Before touching projects/gossamer/Sources/CLI/Commands/Doctor.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":"GossamerOrbitSyncCoordinator needs a paired pass: change GossamerOrbitSyncCoordinator's known staging timeout from 15 to 30 seconds, plus capture the contract and rollback note for consumers. Use projects/gossamer/config/staging.toml as the source of truth, preserve the FastAPI contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"GossamerAcornWidgetStore's FilterDrawer.vue needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"GossamerEmberRelayCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Unify the GossamerWrenExportStore validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Nimbus: # projects/gossamer/engine/render/atlas.cpp\n[worker.gossamerrainfalldbflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamerrainfalldbflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamerrainfalldbflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerRainfallDBFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47142\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 GossamerRainfallDBFlow'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.3,"slice":"pasted-context","lang":"en"}
{"prompt":"Collapse the GossamerMarbleTokenService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Opal: diff --git a/projects/gossamer/src/sync/reconcile.ts b/projects/gossamer/src/sync/reconcile.ts\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/src/sync/reconcile.ts\n+++ b/projects/gossamer/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 GossamerMoonlitSDKCoordinator 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":"What is the safest way to split projects/gossamer/packages/api/openapi.yaml into independently owned modules while GossamerFlintTimelineFlow's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Clarify GossamerAtlasSearchService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale GossamerSpruceDaemonStore value; the cause, desired value, and affected assertion are already agreed. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep VoiceOver and keyboard navigation working\n- retain the current FastAPI operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Prism: // projects/gossamer/services/ledger/replay.go\nfinal class GossamerBirchMigratorFlowCoordinator {\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Split GossamerBirchMigratorFlow 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":"Production says GossamerNimbusFormService is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep VoiceOver and keyboard navigation working\n- retain the current Swift 6 operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Move GossamerVelaDrawerStore behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Could GossamerNovaPickerStore show the active gRPC sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Security flagged GossamerWillowCodecStore for a read-only pass because its Swift 6 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- keep VoiceOver and keyboard navigation working\n- retain the current Swift 6 operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka monorepo, so keep ownership and handoff points understandable in a small review.\n\nReturn an assessment of the existing artifact; only quote enough to make the walkthrough understandable.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Quartz: What is the safest way to split projects/gossamer/workers/thumbnail/consumer.ex into independently owned modules while GossamerFernSnapshotService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about GossamerBirchMigratorStore, but the current prose in projects/gossamer/web/components/FilterDrawer.vue 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- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing Room deployment\n- keep the work scoped to GossamerBirchMigratorStore and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.\n\nProduce durable prose rather than a code assessment or implementation change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-47131: finish the compact GossamerCoralUploadFlow filter experience\n\nRoute: /catalog/search\nSource: projects/gossamer/apps/console/routes/usage.svelte\nFramework: OpenTelemetry\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\nBring GossamerCoralUploadFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Remove GossamerBasilRunnerService's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"The first GossamerCraneWorkspaceService request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Raven: projects/gossamer/app/src/main/SyncWorker.kt の GossamerOspreyJobFlow で、OpenTelemetry の flow に断続的な問題が起きています。 consumer 向けに contract、error、retry、コピー可能な例を含む文書を書き、handler は変更しないでください。\n\n制約:\n- OpenTelemetry を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は GossamerOspreyJobFlow のみ","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"ja"}
{"prompt":"Ticket OPS-47122: retire the legacy replay path for GossamerVelaDrawerFlow\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 GossamerVelaDrawerFlow 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":"Summarize the GossamerAtlasSearchStore changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"GossamerWrenExportCoordinator needs a paired pass: change GossamerWrenExportCoordinator's known staging timeout from 15 to 30 seconds, plus capture the contract and rollback note for consumers. Use projects/gossamer/engine/render/atlas.cpp as the source of truth, preserve the Swift 6 contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-47125\n\n08:02 deploy GossamerMosaicGridFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current GossamerMosaicGridFlow 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":"Two engineers disagree about whether GossamerOpalRouterStore's cache is authoritative. Walk the reads and writes in projects/gossamer/config/staging.toml and settle that question from the code. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"GossamerHarborIndexCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Memory attributed to GossamerPrismCacheStore 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":"Why does GossamerGarnetModalStore's gRPC worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Decouple GossamerMapleQueueStore's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Spell GossamerWillowCodecService's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Describe GossamerAcornWidgetService's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"Read projects/gossamer/internal/auth/refresh.go and tell me whether GossamerTideWorkerService 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":"GossamerDriftConsoleCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"GossamerAtlasSearchCoordinator needs a paired pass: finish GossamerAtlasSearchCoordinator's responsive empty and retry states, plus give the existing implementation a read-only safety pass. Use projects/gossamer/src/sync/reconcile.ts as the source of truth, preserve the OpenTelemetry contract, and avoid unrelated cleanup.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Em projects/gossamer/ml/pipeline/features.py, o GossamerFrostPanelStore tem um problema intermitente no fluxo de gRPC. Finalize o layout responsivo, estados vazio e retry, foco por teclado, dark mode e reduced motion.\n\nRestrições:\n- continuar com gRPC\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao GossamerFrostPanelStore","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"pt"}
{"prompt":"projects/gossamer/web/components/FilterDrawer.vue の GossamerHarborIndexService で、Room の flow に断続的な問題が起きています。 原因は判明済みです。staging timeout だけを 15 秒から 30 秒へ変え、対応する assertion を直してください。\n\n制約:\n- Room を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は GossamerHarborIndexService のみ","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"ja"}
{"prompt":"projects/gossamer/db/migrations/20260730_events.sql has grown through several launches, and GossamerMoonlitSDKService 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- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing OpenTelemetry deployment\n- keep the work scoped to GossamerMoonlitSDKService and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"GossamerEchoRegistryStore crashes after reconnect","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/gossamer/lib/codec/frame.cc b/projects/gossamer/lib/codec/frame.cc\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/lib/codec/frame.cc\n+++ b/projects/gossamer/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\nSplit GossamerPrismCacheCoordinator 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":"Bring GossamerCedarPolicyService'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":"GossamerFernSnapshotStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/gossamer/ui/settings/PrivacyPane.tsx and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Sable: Ticket OPS-47116: retire the legacy replay path for GossamerEmberRelayFlow\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 GossamerEmberRelayFlow 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":"Incident timeline — INC-47155\n\n08:02 deploy GossamerGarnetModalCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current GossamerGarnetModalCoordinator 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":"Tide: Ticket OPS-47126: retire the legacy replay path for GossamerAtlasSearchFlow\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 GossamerAtlasSearchFlow 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":"GossamerPineMetricsCoordinator: polish the last piece","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Draft GossamerVelaDrawerService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"For GossamerAcornWidgetCoordinator, separate GossamerAcornWidgetCoordinator's policy from transport without behavior changes; once that is complete, correct the known stale timeout beside it. Work from projects/gossamer/web/components/FilterDrawer.vue, stay with Room, and keep VoiceOver and keyboard navigation working. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Could GossamerCopperBridgeService show the active FastAPI 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":"Does GossamerMoonlitSDKFlow enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The behavior of GossamerRavenSessionStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/gossamer/infra/modules/edge/main.tf. 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- keep VoiceOver and keyboard navigation working\n- retain the current Room operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka monorepo, so keep ownership and handoff points understandable in a small review.\n\nProduce durable prose rather than a code assessment or implementation change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"GossamerLumenChartCoordinator is blocking the next release because an accessibility label that reads the internal enum. I need two concrete outcomes from a single pass: finish GossamerLumenChartCoordinator's responsive empty and retry states, and capture the contract and rollback note for consumers. Use the existing Swift 6 conventions in projects/gossamer/engine/render/atlas.cpp; keep VoiceOver and keyboard navigation working. 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":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Sketch the GossamerEchoRegistryService migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/gossamer/src/sync/reconcile.ts: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: gossamerslateeditorflow::scheduler::LeaseTask::flush\n at ./projects/gossamer/src/sync/reconcile.ts:217:18\n 4: gossamerslateeditorflow::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 GossamerSlateEditorFlow 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":"Two deliverables are holding up GossamerMicaProfileCoordinator. First, assess ownership and failure handling in projects/gossamer/Sources/CLI/Commands/Doctor.swift. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/gossamer/Sources/CLI/Commands/Doctor.swift, which follows gRPC conventions and currently suffers from lost focus when the drawer animation finishes. Keep voiceover and keyboard navigation working.\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":"GossamerEchoRegistryCoordinator: diagnose, then document","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Umbra: # projects/gossamer/infra/modules/edge/main.tf\n[worker.gossamerravensessioncoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamerravensessioncoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamerravensessioncoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerRavenSessionCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47158\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/gossamer/infra/modules/edge/main.tf. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-47118: retire the legacy replay path for GossamerEchoRegistryFlow\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 GossamerEchoRegistryFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"Vela: // projects/gossamer/apps/console/routes/usage.svelte\nfinal class GossamerCinderAuthFlowCoordinator {\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 GossamerCinderAuthFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"GossamerCloudReconcilerCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"In projects/gossamer/apps/console/routes/usage.svelte hat GossamerCinderAuthService ein sporadisches Problem im OpenTelemetry-Ablauf. Verfolge Queue, Scheduler und Abbruch, vergleiche Hypothesen und finde die Ursache vor jeder Änderung.\n\nRandbedingungen:\n- OpenTelemetry weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf GossamerCinderAuthService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um GossamerCinderAuthService mit OpenTelemetry kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"UI ticket DES-47151: finish the compact GossamerOspreyJobCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/gossamer/apps/console/routes/usage.svelte\nFramework: OpenTelemetry\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 GossamerOspreyJobCoordinator'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":"Pin GossamerOrbitSyncService's FastAPI dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Exponha retryAfter em GossamerIrisBatchService","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"GossamerQuartzPlayerCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Willow: Incident timeline — INC-47141\n\n08:02 deploy GossamerCedarPolicyFlow 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 GossamerCedarPolicyFlow 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":"GossamerSlateEditorCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current GossamerFlintTimelineStore design actually guarantees what its callers assume. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside GossamerFlintTimelineStore\n- keep VoiceOver and keyboard navigation working\n\nThe relevant code crosses healthcare, Svelte, Kafka. Prefer evidence from the repository and make any assumption explicit.\n\nReturn an assessment of the existing artifact; only quote enough to make the walkthrough understandable.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Xylem: Incident timeline — INC-47157\n\n08:02 deploy GossamerNimbusFormCoordinator 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 GossamerNimbusFormCoordinator, 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":"diff --git a/projects/gossamer/workers/thumbnail/consumer.ex b/projects/gossamer/workers/thumbnail/consumer.ex\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/workers/thumbnail/consumer.ex\n+++ b/projects/gossamer/workers/thumbnail/consumer.ex\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is GossamerWillowCodecFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"GossamerJuniperCLIService'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":"Spell GossamerCoralUploadStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"On compact widths, GossamerQuartzPlayerStore'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.6,"slice":"core","lang":"en"}
{"prompt":"Assess the GossamerKiteSchedulerStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a misleading timeout name used in five packages in GossamerMoonlitSDKStore, 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":"Yarrow: diff --git a/projects/gossamer/crates/index/src/segment.rs b/projects/gossamer/crates/index/src/segment.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/crates/index/src/segment.rs\n+++ b/projects/gossamer/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\nAdd the bounded GossamerQuartzPlayerFlow 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.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Two asks around GossamerCoralUploadCoordinator: (1) separate GossamerCoralUploadCoordinator's policy from transport without behavior changes; (2) give the existing implementation a read-only safety pass. Keep voiceover and keyboard navigation working, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Fresh release brief for GossamerCinderAuthCoordinator:\n- primary outcome: lay out a staged migration for GossamerCinderAuthCoordinator\n- companion outcome: then implement the bounded durable-cursor handler\n- repository entry point: projects/gossamer/app/src/main/SyncWorker.kt\n- platform constraint: OpenTelemetry\n- known complication: timestamps rendered one day ahead near UTC midnight\n\nBoth results are required, but they should remain independently reviewable. Keep voiceover and keyboard navigation working; 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":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"GossamerOspreyJobStore'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":"Zephyr: Two asks around GossamerAmberFilterCoordinator: (1) assess ownership and failure handling in projects/gossamer/infra/modules/edge/main.tf; (2) capture the contract and rollback note for consumers. Keep voiceover and keyboard navigation working, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"En projects/gossamer/app/src/main/SyncWorker.kt, GossamerCinderAuthStore tiene un problema intermitente en el flujo de OpenTelemetry. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con OpenTelemetry\n- conservar compatibilidad y cancelación\n- limitar el cambio a GossamerCinderAuthStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con OpenTelemetry alrededor de GossamerCinderAuthStore.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"GossamerFernSnapshotCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"What sequence would let GossamerJuniperCLIStore adopt FastAPI with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Checkout: # projects/gossamer/crates/index/src/segment.rs\n[worker.gossamersprucedaemonflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossamersprucedaemonflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossamersprucedaemonflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerSpruceDaemonFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47114\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/gossamer/crates/index/src/segment.rs and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"We expect GossamerEmberRelayStore to outgrow its current OpenTelemetry 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- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing OpenTelemetry deployment\n- keep the work scoped to GossamerEmberRelayStore and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'GossamerCopperBridgeFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[GossamerCopperBridgeFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/gossamer/pkg/cache/lease.rs:144: error: -[GossamerCopperBridgeFlowTests 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 '-[GossamerCopperBridgeFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nDetermine why GossamerCopperBridgeFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"PM is preparing the GossamerLumenChartStore 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 GossamerLumenChartStore\n- keep VoiceOver and keyboard navigation working\n\nThe relevant code crosses healthcare, Svelte, Kafka. Prefer evidence from the repository and make any assumption explicit.\n\nProduce durable prose rather than a code assessment or implementation change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Corrige le timeout de GossamerIrisBatchStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"fr"}
{"prompt":"Sketch the GossamerSummitProxyStore migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-47159: finish the compact GossamerFlintTimelineCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/gossamer/config/staging.toml\nFramework: FastAPI\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible GossamerFlintTimelineCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/gossamer/internal/auth/refresh.go b/projects/gossamer/internal/auth/refresh.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/internal/auth/refresh.go\n+++ b/projects/gossamer/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 GossamerTideWorkerFlow'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":"Support wants the behavior in projects/gossamer/workers/thumbnail/consumer.ex recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-47138: retire the legacy replay path for GossamerLedgerGateFlow\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 GossamerLedgerGateFlow 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":"GossamerTideWorkerCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about GossamerFlintTimelineService, but the current prose in projects/gossamer/packages/api/openapi.yaml 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- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing FastAPI deployment\n- keep the work scoped to GossamerFlintTimelineService and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Compare GossamerMarbleTokenStore's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Security flagged GossamerMicaProfileService for a read-only pass because its gRPC 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- keep VoiceOver and keyboard navigation working\n- retain the current gRPC operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: GossamerMicaProfileStore has one known configuration mistake in projects/gossamer/Sources/CLI/Commands/Doctor.swift, 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- keep VoiceOver and keyboard navigation working\n- stay compatible with the existing gRPC deployment\n- keep the work scoped to GossamerMicaProfileStore and its direct tests\n\nThis repository spans healthcare, Svelte, Kafka; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Outline a safer GossamerKiteSchedulerService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The GossamerOpalRouterService surface in projects/gossamer/packages/api/openapi.yaml 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":"Exporter: Two asks around GossamerMosaicGridCoordinator: (1) ship the idempotent GossamerMosaicGridCoordinator replay endpoint; (2) give the existing implementation a read-only safety pass. Keep voiceover and keyboard navigation working, and leave a clear boundary between the resulting artifacts or edits.","purpose":"backendImpl","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"# projects/gossamer/packages/api/openapi.yaml\n[worker.gossameropalrouterflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossameropalrouterflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossameropalrouterflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerOpalRouterFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47149\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/gossamer/packages/api/openapi.yaml. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"# projects/gossamer/services/ledger/replay.go\n[worker.gossameracornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.gossameracornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.gossameracornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.GossamerAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-47133\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 GossamerAcornWidgetFlow'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":"Add a bounded GossamerCopperBridgeStore 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":"For GossamerIrisBatchCoordinator, produce a consumer guide for GossamerIrisBatchCoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/gossamer/workers/thumbnail/consumer.ex, stay with Swift 6, and keep VoiceOver and keyboard navigation working. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Check GossamerMapleQueueService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"GossamerKiteSchedulerCoordinator: restructure, then correct","purpose":"refactor","secondary":"backendImpl","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"GossamerGarnetModalFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/gossamer/ml/pipeline/features.py and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Decouple GossamerSpruceDaemonService's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"GossamerOpalRouterCoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Three teams extended GossamerDeltaCanvasService 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- keep VoiceOver and keyboard navigation working\n- retain the current FastAPI operational envelope\n\nSeveral teams work in this healthcare, Svelte, Kafka 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":"Scheduler: diff --git a/projects/gossamer/lib/codec/frame.cc b/projects/gossamer/lib/codec/frame.cc\nindex 62d71aa..90f3c1e 100644\n--- a/projects/gossamer/lib/codec/frame.cc\n+++ b/projects/gossamer/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 GossamerLumenChartFlow'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":"Investigate the GossamerMosaicGridService hang","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind GossamerSlateEditorStore's OpenTelemetry choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Does GossamerAmberFilterStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
data/round2-08.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "the agent one", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "claims stopped auto-assigning overnight and there's nothing obviously wrong:\n\nActiveJob::DeserializationError: Error while trying to deserialize arguments: Couldn't find Claim with 'id'=88412\n from /app/vendor/bundle/ruby/3.3.0/gems/activejob-7.2.1/lib/active_job/arguments.rb:88:in `deserialize_global_id'\n from /app/app/jobs/auto_assign_job.rb:12:in `perform'\n\nSidekiq::Job dead: AutoAssignJob args=[gid://claims/Claim/88412] retries=25\nDead set size: 4,118\n\nclaims created in the last hour: 1,204\nclaims assigned: 0\nclaims table max id: 88,401\n\nsomething is enqueuing jobs for claims that don't exist yet", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "claim documents upload fine and then can't be downloaded, about 1 in 200:\n\nAws::S3::Errors::NoSuchKey (The specified key does not exist.):\n app/services/documents/fetch.rb:41:in `download'\n app/controllers/documents_controller.rb:22:in `show'\n\nupload log for the same document:\n 11:02:14 direct upload started key=claims/88412/scan-001.pdf size=4.1MB\n 11:02:19 direct upload completed etag=\"9c1d0044410bb7b77e91030cc219e1f0\"\n 11:02:19 Document record created id=41882 key=claims/88412/scan-001.pdf\n 11:02:20 antivirus scan queued\n 11:02:44 antivirus scan passed\n 11:02:44 document moved to claims/88412/clean/scan-001.pdf\n\nthe Document row still points at the pre-scan key", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "pipeline caches restore into the wrong workspace occasionally and builds fail bizarrely:\n\ncache key: deps-{{ checksum \"go.sum\" }}-linux-amd64\nrestored from: deps-9c1d0044410bb7b77e91030cc219e1f0a-linux-amd64\nrestore path: /workspace/.cache/go-build\n\nbuild output:\n # github.com/lumen/claims/internal/rating\n internal/rating/table.go:41:2: cannot find package \"github.com/lumen/claims/internal/tariff\"\n note: module github.com/lumen/claims requires go >= 1.24, running go1.22\n\nagent reports:\n workspace /workspace reused from previous job (pipeline 8f2b1c, repo lumen/billing)\n cleanup: skipped (fast-path enabled)", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "our claims dashboard times out for the largest broker and the correlated subqueries are the obvious suspect, but i'd like the actual profile before rewriting. work out where the time goes, then restructure the query so the page loads for a broker with four hundred thousand claims", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "the pipeline parser validates inconsistently, ignores some problems silently, and duplicates the API's own validation. consolidate it, and while you're there confirm whether any currently-accepted pipeline would start failing — i'd rather know than find out from a customer customers write these files by hand, so a newly-rejected pipeline is a support ticket.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "plugin host segfaults during automation recording, roughly once an hour:\n\nProgram received signal SIGSEGV, Segmentation fault.\n0x00007ffff7a2c118 in juce::AudioProcessorValueTreeState::Parameter::setValueNotifyingHost(float) ()\n(gdb) bt\n#0 juce::AudioProcessorValueTreeState::Parameter::setValueNotifyingHost(float)\n#1 0x0000555555601a44 in AutomationRecorder::processBlock(juce::AudioBuffer<float>&) at src/AutomationRecorder.cpp:141\n#2 0x00005555556220c8 in PluginProcessor::processBlock(juce::AudioBuffer<float>&) at src/PluginProcessor.cpp:88\n#3 0x00007ffff7b0a112 in juce::AudioProcessorGraph::processBlock()\n(gdb) info threads\n Id Target Id Frame\n* 1 Thread (audio) setValueNotifyingHost\n 2 Thread (message) juce::MessageManager::runDispatchLoop\n\nsetValueNotifyingHost is being called from the audio thread, which the docs say not to do", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "claim rating engine's caching, which i inherited last week:\n\nclass Rating::Engine\n CACHE = {}\n\n def self.rate(claim)\n CACHE[claim.id] ||= begin\n policy = claim.policy.version_at(claim.incident_at)\n factors = policy.factors.map { |f| f.evaluate(claim) }\n Money.new(factors.sum { |f| f.amount_cents }, policy.currency)\n end\n end\nend\n\npuma with four workers and five threads each, claims are rated on every page view of the claim detail screen, and policy versions change when an underwriter edits them", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "pipeline definition format, which customers write by hand. is it as unambiguous as we think?\n\nsteps:\n - name: test\n image: golang:1.24\n commands: [\"go test ./...\"]\n cache:\n key: deps-{{ checksum \"go.sum\" }}\n paths: [\"/go/pkg/mod\", \".cache/go-build\"]\n - name: build\n image: golang:1.24\n depends_on: [test]\n commands: [\"go build -o bin/app\"]\n artifacts: [\"bin/app\"]\n - name: deploy\n when: { branch: main, event: push }\n image: alpine\n commands: [\"./deploy.sh\"]\n secrets: [DEPLOY_TOKEN]\n\nthe cache key doesn't include the image or the architecture; `when` on one step doesn't skip its dependents; and secrets are available to any command in the step, including ones that print the environment", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "claims API, integrated by four brokers, documented in a spreadsheet. this is the create endpoint:\n\nPOST /api/v2/claims\n auth: broker API key, scoped to the broker's policies\n body: { policy_number, incident_at, description, claimant: {...}, documents: [{ name, url }] }\n policy_number must exist and be active at incident_at, else 422 policy_not_in_force\n incident_at more than 90 days ago is accepted but flagged for manual review\n documents are fetched asynchronously from the given URLs; a fetch failure does not fail the claim\n the response is 202 with a claim reference, not 201, because assignment happens asynchronously\n duplicate submissions within 24h with the same policy and incident_at return the original reference\n\nwrite the API reference, and make the 202 and the deduplication behaviour impossible to miss", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "our API changelog needs an entry for the claim deduplication window, brokers keep asking", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "three ways of describing a step's status in our codebase, and the API leaks all three:\n\n// internal/agent\ntype StepState int // 0 pending, 1 running, 2 done, 3 failed, 4 killed\n\n// internal/api\ntype StepStatus string // \"queued\" | \"in_progress\" | \"success\" | \"failure\" | \"cancelled\"\n\n// database\nstatus smallint -- 0..4, but 5 and 6 exist in production rows from an old version\n\nthe mapping lives in three switch statements, one of which is missing a case and silently produces \"queued\" for anything unknown", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "what does the blocklist actually block?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "a regulator has asked six questions about rating reproducibility, post-closure edits, document retention, broker isolation, policy corrections and data replication. answer each from the code rather than from what we'd like to be true, and write it as a controls document with anything unsubstantiated clearly marked as such our compliance lead will read it before the regulator does and prefers plain statements.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "plugin SDK has no documentation beyond one example file, and the behaviours third-party developers keep tripping over are exactly the ones we've never written down: the version check that fails silently, the parameter cap that drops the extras, the blocklist after two crashes, and the thirty-second scan timeout counting as a crash. write the integration guide that covers all of it three developers are waiting on this and two of them have already shipped against guesses.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "audio drops out for a few hundred milliseconds when a plugin scan finishes, users are furious:\n\n[audio] callback 512 frames @ 48000 (10.67ms budget)\n[audio] xrun: callback took 24.11ms\n[audio] xrun: callback took 31.88ms\n[scan] plugin scan finished, 412 plugins, 88 new\n[scan] posting to message thread: refreshPluginList()\n[audio] xrun: callback took 41.02ms\n[audio] xrun: callback took 18.44ms\n[audio] 4 dropouts in 200ms\n[ui] plugin list rebuilt, 412 items\n\nrefreshPluginList swaps the shared array the audio thread reads from, under a std::mutex that the audio callback also takes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "design doc for our session format, written before the plugin work. does it still hold?\n\n## Session file\nA session is a single JSON document containing tracks, clips, automation and a plugin manifest. Plugins are referenced by their UID and version. On load, missing plugins are replaced by a placeholder that preserves the parameter state so the session can round-trip.\n\n## Assumptions\n- Sessions are small (< 5MB) and can be parsed on the message thread at load.\n- Plugin UIDs are stable across versions.\n- Automation is sparse enough to store as a list of (time, value) pairs.\n\n## Not covered\nCollaborative editing. Partial loading. Sessions referencing external audio files that have moved.\n\nsessions from our heaviest users are now 40-80MB, and the placeholder path is what's crashing on iOS", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "prod and staging agent config, and staging has never wedged:\n\n# staging/agent.yaml\nagent:\n slots: 2\n fast_path: false\n hard_timeout: 20m\n soft_timeout: 10m\n reaper_interval: 1m\n runtime: docker\n workspace_root: /var/lib/agent/ws\n cleanup_on_release: true\n\n# prod/agent.yaml\nagent:\n slots: 8\n fast_path: true\n hard_timeout: 20m\n soft_timeout: 10m\n reaper_interval: 5m\n runtime: runc\n workspace_root: /mnt/nvme/ws\n cleanup_on_release: false\n\n# prod agent metrics over the last day\n agent_slots_reserved 4 (steady, no running steps)\n agent_steps_started_total rate 0/s for 3h\n agent_reaper_runs_total 12\n agent_reaper_errors_total 12 (\"container not found\")\n\nprod agents have 8 cores; fast_path went on last year to cut build times and nobody has revisited it since", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "one smoothing helper for all processors", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "is the ring buffer safe with std::function?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "i'd like an honest read on whether our rating cache can serve one claim's rating for another under puma's threading, and if it can, the fix — with a test that fails on the current code", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "we have two audio buffer pool implementations, one in the engine and one in the plugin host", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "three third-party developers are blocked on a plugin SDK document that doesn't exist, and writing it will force us to decide which of our current behaviours are the contract and which are accidents — the silent parameter cap, the blocklist, the scan timeout. i want the plan for what we commit to publicly before anyone writes prose", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "what does the antivirus step do with a document it can't scan at all", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a walkthrough of the plugin scan process would help before i touch the blocklist", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "webhook receiver drops events under load and the numbers don't add up:\n\nnginx access log (1 minute sample):\n POST /webhooks/insurer 200 count=8,412\n POST /webhooks/insurer 499 count=1,204\n POST /webhooks/insurer 502 count=118\n\napp side:\n WebhookEvent.where(created_at: 1.minute.ago..).count => 8,180\n Sidekiq queue :webhooks depth => 41,882\n Sidekiq latency :webhooks => 812 seconds\n\npuma: 4 workers × 5 threads, and the receiver writes the event row synchronously before enqueueing\n\nthe insurer retries anything that isn't a 200 within 30 seconds, which is where the 499s come from", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "before this lands, is the lock-free queue actually lock-free the way it's used?\n\ntemplate <typename T, size_t Capacity>\nclass RingBuffer {\n std::array<T, Capacity> data_;\n std::atomic<size_t> head_{0}, tail_{0};\npublic:\n bool push(const T& v) { // called from the message thread\n auto t = tail_.load(std::memory_order_relaxed);\n auto next = (t + 1) % Capacity;\n if (next == head_.load(std::memory_order_acquire)) return false;\n data_[t] = v; // T is std::function<void()>\n tail_.store(next, std::memory_order_release);\n return true;\n }\n bool pop(T& out) { /* mirror, called from the audio thread */ }\n};\n\nthe queue carries std::function objects that capture by value, and the audio thread invokes them", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "agent's step execution, and i want to know whether the cleanup can be skipped safely:\n\nfunc (a *Agent) runStep(ctx context.Context, s Step) error {\n\tws, err := a.workspaces.Acquire(s.PipelineID)\n\tif err != nil { return err }\n\tif !a.fastPath {\n\t\tdefer a.workspaces.Clean(ws)\n\t}\n\tdefer a.workspaces.Release(ws)\n\tid, err := a.runtime.Create(ctx, s.Image, ws.Path)\n\tif err != nil { return err }\n\tdefer a.runtime.Remove(context.Background(), id)\n\tctx, cancel := context.WithTimeout(ctx, s.HardTimeout)\n\tdefer cancel()\n\treturn a.runtime.Wait(ctx, id)\n}\n\nfastPath is on in production, workspaces are reused across pipelines, and Release is also called by a reaper goroutine on timeout", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "la política de reintentos del receptor de webhooks, ¿tiene sentido?\n\nclass WebhooksController < ApplicationController\n skip_before_action :verify_authenticity_token\n\n def insurer\n event = WebhookEvent.create!(payload: params.to_unsafe_h, source: \"insurer\")\n ProcessWebhookJob.perform_later(event.id)\n head :ok\n rescue ActiveRecord::RecordNotUnique\n head :ok\n rescue => e\n Sentry.capture_exception(e)\n head :internal_server_error\n end\nend\n\n# ProcessWebhookJob\nclass ProcessWebhookJob < ApplicationJob\n queue_as :webhooks\n retry_on StandardError, wait: :polynomially_longer, attempts: 25\n\n def perform(id)\n event = WebhookEvent.find(id)\n Insurer::Apply.new(event).call\n event.update!(processed_at: Time.current)\n end\nend\n\nla aseguradora reintenta cualquier respuesta que no sea 200 durante 24 horas y sin espera entre intentos, el payload puede tener 2 MB con adjuntos en base64, y por la mañana nos llegan 40.000 eventos en veinte minutos", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "es"}
{"prompt": "support notes about the plugin scan, they need to become a proper help article:\n\n- first launch scans every plugin on the machine, which for a big library is 10-40 minutes\n- the scan runs in a separate process so a crashing plugin doesn't take the app down\n- a plugin that crashes twice is blocklisted and hidden from the browser, with no visible message\n- users find their plugin \"missing\" and reinstall it, which doesn't help because the blocklist survives\n- the blocklist is in a plist that we've never documented, and clearing it requires the terminal\n- rescanning individual plugins is possible from a preference pane most users never open\n- audio dropouts during the scan are a known issue we're working on\n\nwrite the article, including how to clear the blocklist without making it sound like a defect", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "regulator's question list arrived and answering it properly is the documentation we never wrote:\n\n1. How is a claim's assessed value calculated, and is the calculation reproducible for a claim closed two years ago?\n2. Which roles can alter a claim after it has been closed, and how is that recorded?\n3. How long are claim documents retained, and how is deletion evidenced?\n4. Describe the controls preventing a broker from seeing another broker's claims.\n5. What happens to a claim if the policy version it was rated against is later corrected?\n6. Where is claimant personal data replicated, including backups and analytics?\n\nwork each answer out from the code and write it as a controls document, marking anything you can't substantiate", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "stem export filenames drop the track number", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "queue alert needs a 30 minute window", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "document thumbnails need type badges", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "scan progress strip at the top", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "step status is colour-only in the graph", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "why do sessions take eight seconds to open?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "agents wedge at full capacity", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "session format design doc assumed sessions under five megabytes and stable plugin UIDs, and both assumptions have quietly failed — our heaviest users have eighty megabyte sessions and the placeholder path crashes on iOS. read the doc against the current loader and tell me which of its assumptions still hold i'd like the answer in terms of what breaks next rather than what's already broken.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "audio team's list, which i need to turn into a plan with the september release in mind:\n\n- move all plugin scanning off any lock the audio thread touches\n- lazy session loading, because 80MB sessions block the message thread for seconds\n- fix the MIDI timing drift, which is a rounding bug in the scheduler and probably a day's work\n- replace the three copies of plugin state with one owner\n- automation recording currently calls host APIs from the audio thread, which is why it segfaults\n- surface the plugin blocklist in the UI instead of hiding it in a plist\n\nthe release is in six weeks, and QA needs two of those", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the plugin browser, which is currently a flat list of 400 items:\n\nPlugin browser\n- Left rail: categories (Instruments, Effects, Utility) with counts, plus Favourites and Recently Used.\n- Grid of cards, 160x120, showing the plugin name, vendor, format badge (VST3/AU/AAX) and a favourite star.\n- Virtualised; scrolling 2,000 plugins must stay at 60fps on a 2019 MacBook.\n- Search filters as you type with a 120ms debounce, matching name and vendor, highlighting the match.\n- Blocklisted plugins appear greyed with a warning glyph, a tooltip explaining why, and a Rescan action.\n- While a scan is running, a progress strip at the top shows the current plugin name and a Cancel button.\n- Drag a card onto a track to instantiate; the drag image is the card at 60% opacity.\n- Keyboard: type-ahead selection, enter instantiates on the selected track, space previews.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "one owner for the plugin list", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand how a claim's assessed value is recalculated when the policy version changes", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "is our session loader doing anything on the audio thread, or is that just where it crashes", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "prod agents run eight slots on eight cores, which is why steps time out rather than queue", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "we need a plan for supporting AAX, which means a different SDK, signing, and a certification process", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "build agents wedge on a subset of pipelines and the only trace is this:\n\ntime=2026-07-29T11:02:14Z level=info msg=\"step started\" pipeline=8f2b1c step=test image=golang:1.24\ntime=2026-07-29T11:02:15Z level=info msg=\"container created\" id=a11c3f2 runtime=runc\ntime=2026-07-29T11:12:15Z level=warn msg=\"step exceeded soft timeout\" elapsed=10m0s\ntime=2026-07-29T11:22:15Z level=warn msg=\"step exceeded hard timeout, sending SIGTERM\" elapsed=20m0s\ntime=2026-07-29T11:22:45Z level=error msg=\"container did not exit, sending SIGKILL\"\ntime=2026-07-29T11:22:45Z level=error msg=\"kill failed\" err=\"container not found: a11c3f2\"\ntime=2026-07-29T11:22:45Z level=info msg=\"agent marked step failed, releasing slot\"\ntime=2026-07-29T11:22:46Z level=error msg=\"slot release failed: slot already released\"\n\nafter this the agent reports capacity 4/4 forever and takes no new work", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "iOS build of our sampler crashes on launch for some users only:\n\nException Type: EXC_BAD_ACCESS (SIGSEGV)\nException Subtype: KERN_INVALID_ADDRESS at 0x0000000000000018\nTermination Reason: SIGNAL 11 Segmentation fault: 11\n\nThread 0 Crashed:\n0 Sampler 0x104a2c118 juce::AudioProcessorGraph::rebuild() + 216\n1 Sampler 0x104b19a44 SamplerEngine::loadSession(juce::File const&) + 388\n2 Sampler 0x1051220c8 SessionRestore::restoreLast() + 296\n3 Sampler 0x104f0a112 -[AppDelegate application:didFinishLaunchingWithOptions:] + 148\n\nonly users whose last session referenced a plugin that has since been deleted from the device", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "das MIDI-Timing driftet bei langen Sessions, hier die Messwerte:\n\nEvent-Nr Soll (ms) Ist (ms) Abweichung\n1 0.00 0.02 +0.02\n1000 125000.00 125041.10 +41.10\n5000 625000.00 625208.44 +208.44\n10000 1250000.00 1250417.02 +417.02\n20000 2500000.00 2500834.88 +834.88\n\nSample-Rate 48000, Buffer 512, Host-Tempo 120 BPM konstant\ndie Abweichung wächst linear, etwa 0,33 ms pro 1000 Events\nwir rechnen die Event-Zeit in Samples um und runden dabei auf ganze Samples ab", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "de"}
{"prompt": "rails app leaks memory in production and restarts every six hours on the memory limit:\n\nrss over 6 hours: 420MB → 2.8GB, linear\nobjects allocated (GC.stat[:total_allocated_objects]) at restart: 4.1e9\nheap_live_slots: 41,882,104\n\nderailed exec perf:mem_over_time top allocations:\n app/services/rating/engine.rb:88 1.2GB Hash allocations\n app/models/claim.rb:212 0.8GB String allocations\n activerecord (7.2.1) query cache 0.4GB\n\nrating/engine.rb:88 is inside a loop over policy versions, memoising into a class-level hash keyed by claim id", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "the claim detail screen needs the document virus-scan states visible, and support needs the help article explaining what a rejected document means. do both, and keep the read-only broker view free of edit affordances", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "claims stopped auto-assigning overnight", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "claim reference is lowercase in emails", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "pipeline parser has grown organically and validation is scattered through it:\n\nfunc Parse(b []byte) (*Pipeline, error) {\n\tvar p Pipeline\n\tif err := yaml.Unmarshal(b, &p); err != nil { return nil, err }\n\tfor i, s := range p.Steps {\n\t\tif s.Name == \"\" { return nil, fmt.Errorf(\"step %d: name required\", i) }\n\t\tif !nameRe.MatchString(s.Name) { return nil, fmt.Errorf(\"step %s: bad name\", s.Name) }\n\t\tif s.Image == \"\" && s.Plugin == \"\" { return nil, fmt.Errorf(\"step %s: image required\", s.Name) }\n\t\tfor _, d := range s.DependsOn {\n\t\t\tif !p.has(d) { return nil, fmt.Errorf(\"step %s: unknown dependency %s\", s.Name, d) }\n\t\t}\n\t\tif s.Cache.Key != \"\" && len(s.Cache.Paths) == 0 { /* silently ignored */ }\n\t\tp.Steps[i] = applyDefaults(s)\n\t}\n\treturn &p, detectCycles(&p)\n}\n\nerror messages are inconsistent, some problems are silently ignored, and the same validation is duplicated in the API's own request validator", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "our health check reports the agent healthy while it has zero free slots and no running steps", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "the claims UI uses eleven hardcoded colours and three custom focus styles, one of which removes the ring. move it onto the tokens, and tell me which status colours will visibly change for adjusters who have used this for years", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "plugin browser is a flat list of four hundred items that scrolls badly on older machines, and it's the first thing every reviewer complains about. build the browser to the new spec — categories, virtualised card grid, search with highlighting, blocklist state visible — and keep drag-to-instantiate working exactly as it does today our oldest supported machine is a 2019 MacBook Pro, which is what the 60fps target refers to.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "claim documents are occasionally unreachable after upload, and the pattern seems to be that the antivirus step moves the object while the database row keeps the original key. i'd like that confirmed properly rather than assumed, including what happens when the scan fails and whether any documents are currently orphaned roughly one in two hundred, and support has three examples with timestamps if that helps.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "pipeline YAML format has grown features that interact badly — `when` not skipping dependents, cache keys that ignore the image, secrets visible to every command in a step — and customers write these by hand. before we add anything else i'd like a view on whether this is a versioned format change or a set of fixes we can make compatibly", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "claims thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "our on-premise CI customers upgrade by replacing a binary and have no migration story for config", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "three query objects each define what \"this broker's claims\" means, two of them interpolate the search term straight into SQL, and they disagree about whether closed claims are included. consolidate them into one scope with one definition, keep the exported CSV byte-identical for a sample of brokers, and get rid of the interpolation while you're in there the export is what brokers reconcile against, so a changed row count would be noticed immediately.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "what guarantees does the agent make about artifact upload when a step is killed mid-write", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "a short note explaining why sessions are moving to lazy loading, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "plugin SDK document has to exist before we can onboard the three developers waiting on it, and writing it will surface behaviours we should probably change rather than document. write the guide, and give me the separate list of things you'd rather fix than commit to the silent version check is the one i'd most like to stop defending in writing.", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "SQL behind our claims dashboard, which times out for the largest broker:\n\nSELECT c.id, c.reference, c.status, c.incident_at,\n p.number AS policy_number, b.name AS broker,\n (SELECT SUM(amount_cents) FROM payments pm WHERE pm.claim_id = c.id) AS paid,\n (SELECT COUNT(*) FROM documents d WHERE d.claim_id = c.id) AS docs,\n (SELECT MAX(created_at) FROM claim_notes n WHERE n.claim_id = c.id) AS last_note\nFROM claims c\nJOIN policies p ON p.id = c.policy_id\nJOIN brokers b ON b.id = p.broker_id\nWHERE b.id = $1 AND c.status <> 'closed'\nORDER BY c.incident_at DESC\nLIMIT 50;\n\nclaims 2.1M rows, payments 8.4M, documents 12M, and the broker in question has 400k claims", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "concurrency model in our scheduler, which decides which agent gets which step:\n\nfunc (s *Scheduler) assign() {\n\ts.mu.Lock()\n\tdefer s.mu.Unlock()\n\tfor _, step := range s.pending {\n\t\tfor _, agent := range s.agents {\n\t\t\tif agent.Free() >= step.Slots && agent.Matches(step.Tags) {\n\t\t\t\tagent.Reserve(step.Slots)\n\t\t\t\tgo s.dispatch(agent, step)\n\t\t\t\ts.remove(step)\n\t\t\t\tbreak\n\t\t\t}\n\t\t}\n\t}\n}\n\nassign runs every second and on every agent heartbeat; dispatch can take up to 30 seconds; Reserve is in-memory only and the agent may already be running steps it accepted from a previous scheduler instance", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "public pipeline YAML reference is a single example with no prose. this is what the parser accepts:\n\nsteps[].name required, unique within the file, [a-z0-9-]{1,40}\nsteps[].image required unless `plugin` is set\nsteps[].commands list of strings, run with `set -e` in a shell\nsteps[].depends_on list of step names; a cycle is a parse error\nsteps[].when map of branch/event/path filters, all must match\nsteps[].cache.key template string, `{{ checksum \"file\" }}` and `{{ env \"VAR\" }}` supported\nsteps[].cache.paths list, relative paths are relative to the workspace root\nsteps[].artifacts list of globs, uploaded on success only\nsteps[].secrets list of secret names, injected as environment variables\nsteps[].matrix map of name to list; expands the step, `matrix.<name>` available in templates\n\nwrite the reference documentation, including that `when` doesn't skip dependents and that cache keys don't include the image", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "o resumo do incidente de ontem, para os corretores. estes são os factos:\n\n09:12 as participações deixam de ser atribuídas automaticamente\n09:31 detetamos que a fila de jobs está a rejeitar tudo com erro de desserialização\n10:02 causa identificada: o job é enfileirado dentro da transação, antes do commit\n10:20 correção aplicada em produção\n10:40 reprocessamento das 1.204 participações em atraso\n11:15 tudo normalizado; nenhuma participação perdida, o atraso máximo foi de duas horas\n\nos corretores viram participações \"por atribuir\" durante duas horas e alguns telefonaram para o apoio; não houve perda de dados nem prazos regulamentares ultrapassados", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "pt"}
{"prompt": "changelog for the desktop app, from the release branch:\n\n41c9e0b fix(audio): plugin scan no longer takes the audio lock\n88f21c0 feat(session): sessions load lazily, large sessions open in under a second\nc0aa774 fix(ios): sessions referencing deleted plugins no longer crash on launch\n2e91b45 feat(midi): sample-accurate event scheduling, fixes long-session drift\naa30f19 fix(browser): blocklisted plugins now show with an explanation and a rescan button\n9c1d004 perf(ui): plugin list virtualised\n4410bb7 chore: minimum macOS is now 13\nb77e910 feat(export): stem export with per-track naming templates\n\nour users are musicians, not engineers; two of these are things they've been complaining about for a year and one is a breaking change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "runbook for a wedged agent is \"restart it\", which loses running builds. what the team actually does:\n\n- symptom is an agent reporting full capacity with no running steps, usually after a container disappears\n- `agentctl slots <agent>` shows the reserved slots and which pipeline reserved them\n- `agentctl release <agent> <slot>` frees one, and the scheduler picks up within a second\n- restarting the agent kills any genuinely running builds, which is why we avoid it\n- if the reaper is the thing that's stuck, its goroutine dump shows it blocked on the runtime socket\n- the underlying bug is that slot release is not idempotent, and we've known that for months\n\nturn this into a runbook page, and be clear about which steps are safe during working hours", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "我们的插件开发文档只有一页示例代码，需要正式的接入说明。目前 SDK 的实际行为如下：\n\n- 插件必须导出 `lumen_plugin_entry`，返回描述结构体；结构体里的 `abi_version` 必须与 SDK 主版本号一致，否则宿主会静默跳过，不打印任何日志\n- 参数上限为 512 个，超出的部分在注册阶段被丢弃，既不报错也不警告\n- `processBlock` 在音频线程调用，禁止分配内存、加锁、访问文件系统或调用任何宿主 API\n- `getStateInformation` 返回的数据会原样写入会话文件；没有硬性大小限制，但超过 1MB 会明显拖慢会话加载\n- `setStateInformation` 可能在音频线程停止之前被调用，插件必须自行处理并发\n- 插件连续崩溃两次后进入黑名单，黑名单保存在用户目录的 plist 文件里，我们从未对外说明过，用户只会发现插件“消失了”\n- 扫描在独立进程中进行，单个插件超时时间是 30 秒，超时同样计入崩溃次数\n- 参数自动化的写入频率上限是每个采样块一次，超过的调用会被静默合并\n\n请写成面向第三方开发者的接入文档，把黑名单、超时和参数上限这三件事写清楚，其余按常规接口说明组织\n\n目前的示例代码就是这一段，文档里也只有这些：\n\nextern \"C\" LumenPluginDescription* lumen_plugin_entry(void) {\n static LumenPluginDescription d = {\n .abi_version = LUMEN_ABI_VERSION,\n .uid = \"com.example.reverb\",\n .name = \"Example Reverb\",\n .vendor = \"Example Audio\",\n .num_parameters = 4,\n .create = &create_instance,\n .destroy = &destroy_instance,\n };\n return &d;\n}\n\nstatic void process_block(LumenPlugin* self, float** io, int channels, int frames) {\n // 这里不能分配内存、不能加锁、不能调用宿主 API\n}", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "zh"}
{"prompt": "rubocop and brakeman before the gate goes on:\n\napp/controllers/webhooks_controller.rb:12:5: W: Rails/SkipsModelValidations: Avoid using `update_all`\napp/services/rating/engine.rb:8:3: C: Style/ClassVars: Class variable @@cache is used\napp/models/claim.rb:141:9: C: Metrics/AbcSize: Assignment Branch Condition size for assign is too high. [<12, 28, 9> 32.08/17]\n\nBrakeman:\n Confidence: High\n Category: Mass Assignment\n Check: MassAssignment\n Message: Parameters should be whitelisted for mass assignment\n File: app/controllers/webhooks_controller.rb\n Line: 6\n\n Confidence: Medium\n Category: SQL Injection\n Check: SQL\n Message: Possible SQL injection\n File: app/queries/claims_search.rb\n Line: 88", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "clang-tidy on the audio engine, and two of these are the ones that bite:\n\nsrc/AutomationRecorder.cpp:141:9: warning: function 'processBlock' calls 'setValueNotifyingHost' which may allocate [audio-thread-safety]\nsrc/SamplerEngine.cpp:88:22: warning: 'std::function' invoked on the audio thread may allocate on copy [performance-no-automatic-move]\nsrc/SessionRestore.cpp:41:5: warning: 'get' on possibly null pointer [bugprone-unchecked-optional-access]\nsrc/PluginScanner.cpp:212:13: warning: lock acquired in a real-time context [audio-thread-safety]\nsrc/UI/PluginList.cpp:19:1: warning: function exceeds recommended size [readability-function-size]\n\n5 warnings; the two audio-thread-safety ones correspond exactly to our two worst crash clusters", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "CI for the audio engine takes 50 minutes and most of it is this:\n\njobs:\n build:\n strategy:\n matrix:\n os: [macos-14, macos-15, ubuntu-24.04, windows-2022]\n config: [Debug, Release]\n steps:\n - uses: actions/checkout@v4\n with: { submodules: recursive }\n - run: cmake -B build -DCMAKE_BUILD_TYPE=${{ matrix.config }}\n - run: cmake --build build --parallel\n - run: ctest --test-dir build --output-on-failure\n\nno ccache, no build cache action, JUCE is a submodule that gets fully rebuilt every time, and Debug builds are only ever looked at when something fails", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "bundler audit on the rails app, which of these go in today:\n\nName: rack\nVersion: 3.0.9\nAdvisory: CVE-2026-10884\nCriticality: Medium\nSolution: upgrade to >= 3.0.11\n\nName: nokogiri\nVersion: 1.16.2\nAdvisory: CVE-2026-11221\nCriticality: High\nSolution: upgrade to >= 1.17.1\n\nName: sidekiq\nVersion: 7.2.0\nAdvisory: GHSA-4c8f (web UI XSS in the busy page)\nCriticality: Medium\nSolution: upgrade to >= 7.3.2\n\nour sidekiq web UI is behind SSO and only reachable from the office network", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "terraform for our build agents, someone spotted this during an unrelated review:\n\nresource \"aws_instance\" \"agent\" {\n count = var.agent_count\n instance_type = \"c7i.4xlarge\"\n vpc_security_group_ids = [aws_security_group.agent.id]\n user_data = templatefile(\"agent.sh.tpl\", { token = var.agent_token })\n metadata_options {\n http_tokens = \"optional\"\n }\n}\n\nresource \"aws_security_group_rule\" \"agent_ssh\" {\n type challenge = \"ingress\"\n from_port = 22\n to_port = 22\n cidr_blocks = [\"0.0.0.0/0\"]\n}\n\nthe agent token is a long-lived credential that can register new agents", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "agent's configuration, documented by its flag help and nothing else:\n\n --workspace-root string where job workspaces are created (default \"/var/lib/agent/ws\")\n --fast-path reuse workspaces between jobs without cleaning (default false)\n --slots int concurrent steps this agent will accept (default 4)\n --tags strings labels used for step matching\n --hard-timeout duration kill a step after this (default 20m)\n --soft-timeout duration warn after this (default 10m)\n --reaper-interval duration how often to look for orphaned containers (default 1m)\n --runtime string runc | docker | podman (default \"runc\")\n\nwhat operators actually need to know: fast-path is why one customer's builds see another repo's files; slots above the core count causes step timeouts rather than queueing; the reaper is the only thing that recovers a leaked slot, and it doesn't handle the case where the container is already gone\n\nwrite the operator's configuration guide", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "les seuils d'alerte de la file d'attente, on nous réveille pour rien :\n\n- alert: WebhookQueueDepth\n expr: sidekiq_queue_size{queue=\"webhooks\"} > 1000\n for: 1m\n labels: { severity: page }\n\n- alert: WebhookQueueLatency\n expr: sidekiq_queue_latency{queue=\"webhooks\"} > 60\n for: 1m\n labels: { severity: page }\n\ncomportement normal : chaque matin à 6h l'assureur envoie un lot de 40 000 événements, la file monte à 40 000 et se vide en vingt minutes\nincident réel du mois dernier : la file est restée à 200 000 pendant six heures sans que personne ne le remarque, parce que tout le monde avait coupé les alertes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "fr"}
{"prompt": "same parameter-smoothing code exists in four processors with different time constants:\n\n// Gain.cpp\nsmoothed = smoothed * 0.99f + target * 0.01f;\n\n// Filter.cpp\nconst float coeff = std::exp(-1.0f / (0.05f * sampleRate));\nsmoothed = target + (smoothed - target) * coeff;\n\n// Delay.cpp\nsmoothed += (target - smoothed) * (1.0f / 64.0f);\n\n// Reverb.cpp\njuce::SmoothedValue<float> smoothed; // ramp length 0.02s, set once in prepareToPlay\n\nthree of them are sample-rate dependent in ways their authors probably didn't intend, and only the reverb one is reset on prepareToPlay", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "this service object has grown to 400 lines and the tests take a database. same behaviour, testable pieces:\n\nclass Claims::Assign\n def initialize(claim, actor: nil, force: false)\n @claim, @actor, @force = claim, actor, force\n end\n\n def call\n return if @claim.assigned? && !@force\n candidates = Adjuster.active.where(region: @claim.region)\n candidates = candidates.where(specialism: @claim.peril) if @claim.complex?\n candidates = candidates.reject { |a| a.workload > a.capacity }\n chosen = candidates.min_by { |a| [a.workload, a.last_assigned_at] }\n raise NoAdjusterAvailable if chosen.nil?\n @claim.update!(adjuster: chosen, assigned_at: Time.current)\n AuditLog.create!(subject: @claim, actor: @actor || \"system\", action: \"assign\")\n AdjusterMailer.assigned(chosen, @claim).deliver_later\n Slack.notify(chosen.slack_id, \"New claim #{@claim.reference}\") if chosen.slack_id\n Metrics.increment(\"claims.assigned\", tags: [\"region:#{@claim.region}\"])\n end\nend", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "unsere Zustandsverwaltung im Plugin-Browser ist dreifach vorhanden:\n\n// PluginList.cpp — hält eine eigene sortierte Kopie\nstd::vector<PluginDescription> items;\n\n// PluginScanner.cpp — hält die Rohliste plus Blockliste\nstd::vector<PluginDescription> scanned;\nstd::set<juce::String> blocked;\n\n// SessionRestore.cpp — hält eine Map von UID auf Beschreibung\nstd::map<juce::String, PluginDescription> byUid;\n\ndrei Kopien derselben Daten, die über Callbacks synchron gehalten werden, und der Audio-Thread liest zwei davon", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "query objects each build their own filtering and they've drifted:\n\n# claims_search.rb\nscope = Claim.where(broker_id: broker.id)\nscope = scope.where(\"reference ILIKE ?\", \"%#{params[:q]}%\") if params[:q]\n\n# claims_export.rb\nscope = Claim.joins(:policy).where(policies: { broker_id: broker.id })\nscope = scope.where(\"claims.reference ILIKE :q OR claimants.surname ILIKE :q\", q: \"%#{params[:q]}%\")\n\n# api/v2/claims_controller.rb\nscope = current_broker.claims\nscope = scope.search(params[:q]) if params[:q].present?\n\nthree different definitions of \"this broker's claims\" and two of them interpolate the search term directly", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "half-year planning input, i need it turned into something sequenced:\n\n- the audio dropout problem is our worst review driver and the fix touches the plugin scanner, the session loader and the UI\n- a regulator audit of the claims platform is booked for february and we have no controls documentation\n- the CI platform's biggest customer wants isolated agents, which fast-path workspace reuse makes impossible\n- ios sessions crash on launch for a small but vocal group of users\n- one engineer is shared across the audio engine and the CI agent and is the only person who understands either\n- we owe a plugin SDK document to three third-party developers who are blocked without it\n- there's a macOS release in september that we cannot move", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket for the CI platform, needs thinking before code:\n\nCI-330 — Workspace isolation\nAgents currently reuse workspaces between jobs with cleanup disabled for speed, which is why one customer occasionally sees another repo's files. The proposal is a workspace per job on an overlay filesystem, with the lower layer being a warm cache of dependencies. Concerns: build times went up 40% in a naive experiment; the overlay approach ties us to specific kernels which our on-premise customers may not have; artifacts and caches currently assume a stable path; and we have no way to prove isolation to a customer once we've claimed it.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "regulator's expectations, as our compliance lead summarised them:\n\n\"Rating decisions must be reproducible for the lifetime of the claim plus seven years. Where a policy version is corrected, claims rated against the earlier version must be identifiable and re-rateable, with both results retained. Personal data of claimants must be deletable on request without destroying the audit trail of the claim itself. Access to claim data by staff must be logged with a business reason, and the log must not be alterable by those staff.\"\n\nwe memoise ratings in a process-local hash, we hard-delete claimant records on request, and our audit log is a table any admin can update. i want the plan, in order of regulatory risk", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the claim detail screen, the one adjusters live in all day:\n\nClaim detail\n- Header: reference, status pill, policy number, incident date, assessed value. Status drives the pill colour and a left border.\n- Three-column layout above 1440px, two below, single column under 900px. The columns are Summary, Documents, Activity.\n- Documents: thumbnail grid with type badges, drag to upload, virus-scan state per document (scanning / clean / rejected), and a rejected document must explain why.\n- Activity: reverse chronological, mixing notes, status changes, payments and emails, with filters per type that persist per user.\n- Notes: inline composer at the top of Activity, markdown, @mention autocomplete of adjusters, optimistic insert with a failure state.\n- Assessed value is editable inline by adjusters only, with the previous value shown on hover and every change recorded.\n- The whole screen must be usable read-only for brokers, with edit affordances absent rather than disabled.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings for our pipeline view, from an enterprise customer's review:\n\n1. The pipeline graph is an SVG with no text alternative; screen reader users cannot tell what ran or what failed.\n2. Step status is conveyed by colour only — green, red, grey circles with no label or shape difference.\n3. Live log output is announced continuously by screen readers, making the page unusable during a build.\n4. The log viewer traps focus; escape does nothing and tab cycles within it forever.\n5. Timestamps are rendered as relative text (\"2m ago\") that never updates and has no absolute value available.\n6. The retry button on a failed step is a div with a click handler.\n7. Contrast on the dimmed log text is 2.9:1.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "insurer's integration spec, we implement the receiving side:\n\nPOST to our endpoint, one event per request, at up to 2,000 requests per second during their morning batch\n headers: X-Insurer-Signature (HMAC-SHA256, hex), X-Insurer-Event-Id (UUID), X-Insurer-Sent-At\n body: up to 2MB of JSON, including base64 document attachments in some event types\n we must respond within 5 seconds; anything else is retried for 24 hours with no backoff\n duplicate event ids are expected (their retries) and must be idempotent\n events must be applied in `sent_at` order per policy, but arrive in any order\n a rejected event (signature failure) should be a 401, which they alert on\n they will disable our endpoint if our error rate exceeds 5% over an hour", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for reproducible ratings, now it needs building:\n\nCREATE TABLE rating_runs (\n id uuid PRIMARY KEY,\n claim_id bigint NOT NULL REFERENCES claims(id),\n policy_version bigint NOT NULL REFERENCES policy_versions(id),\n engine_version text NOT NULL,\n inputs jsonb NOT NULL,\n result_cents bigint NOT NULL,\n currency char(3) NOT NULL,\n created_at timestamptz NOT NULL DEFAULT now(),\n superseded_by uuid REFERENCES rating_runs(id)\n);\n\nevery rating must be recorded, never mutated; re-rating creates a new row and links the old one; the claim detail screen shows the current rating and its history; and a rating must be reproducible from `inputs` plus `engine_version` seven years later, which means the engine's behaviour has to be versioned rather than just its code", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the claims UI actually uses:\n\ntokens:\n color.surface #FFFFFF / #14171A\n color.border #E1E4E8 / #2A2F35\n color.text.default #1B1F23 / #E6EDF3\n color.status.open #0969DA\n color.status.closed #6E7781\n color.status.urgent #CF222E\n space 4/8/12/16/24/32, radius 4/8/12, focus ring 2px offset 2px\n\nthe claims UI: eleven hardcoded colours, four of them near-misses; three custom focus styles, one of which removes the ring entirely; paddings of 6, 10, 14 and 18; and a status colour set that predates the tokens and doesn't match any of them\n\nbring it onto the tokens, keeping the status colours recognisable to adjusters who have used this for years", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "reaper interval back to 1m in prod", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "nokogiri advisory bump", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "en"}
{"prompt": "ccache in the CMake CI job", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "el estado «cerrado» sale en inglés", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "es"}
{"prompt": "ssh open to the world on agents", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "turn fast-path off on prod agents", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "IMDSv2 required on the agent instances", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "Debug-Builds nur noch bei Fehlern bauen", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "de"}
{"prompt": "class variable in the rating engine", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "the claims models have twelve callbacks between them and the order they fire in is load-bearing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "claims platform has one engineer who understands the rating engine and a regulator audit in february, which is a risk in itself. what would you do about the knowledge concentration, given that the honest options are documentation, pairing, or restructuring the engine so it's less clever — and we can probably afford one of them", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "claim assignment does candidate selection, persistence, audit, email, slack and metrics in one method, and the selection logic is the only part anyone wants to test. split it, then document the assignment rules for the operations team who currently guess at them operations currently guess at the rules, and their guesses are wrong in at least two ways.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "pipeline view fails an enterprise customer's accessibility review on seven counts, including a graph with no text alternative and live log output that screen readers read continuously. work through the findings, and where a fix changes the visual design, tell me before you commit to it they've asked for a remediation date, so a rough ordering by effort would help too.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "our audit log is a table any admin can update, which the regulator will notice in february", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "the claim reference in the PDF is generated with a different padding than the one in the UI", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "virtualise the plugin grid", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "format badges on the plugin cards", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "activity feed filters should persist", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "ログビューアからフォーカスが抜けません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
{"prompt": "relative timestamps never update", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "retry button is a div", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "dimmed log text fails contrast", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "pull the notifications out of Claims::Assign", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "one step-status type end to end", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "une seule définition de « sinistres du courtier »", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "fr"}
{"prompt": "`incident_at` naming across the app", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "move parser validation into one place", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "inline the one-line `has()` helper", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "split the 400-line assign service", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "doc comments on the plugin SDK entry point", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "release notes for the september build", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "nota para corretores sobre o incidente", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "pt"}
{"prompt": "document the 202 on claim creation", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the isolation proposal for the team", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "PR description for the scan fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "¿la caché de tarifas es segura entre hilos?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "can a slot leak twice?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through claim assignment", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "dropouts whenever a scan finishes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "warum wächst der Speicher linear?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a claim's rating history", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "keep going on that one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "quieter", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "browser again please", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "your call on the order", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "sort out the mess", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "as before", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "audit stuff", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "encore une passe rapide", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "fr"}
{"prompt": "anything for the release", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "look at it again", "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": "more of the same", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "biggest CI customer wants isolated agents and our fast-path workspace reuse makes that impossible, but turning it off in a naive experiment made builds forty percent slower. i'd like the options for real isolation worked through — overlay filesystems, per-job volumes, or something else — with attention to our on-premise customers whose kernels we don't control, and to the awkward fact that we'd then be making an isolation claim we have to be able to prove", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "regulator expects rating decisions to be reproducible for the life of the claim plus seven years, and today we memoise ratings in a process-local hash and version nothing. work out what reproducibility actually requires of us — inputs, engine versioning, storage, re-rating after a policy correction — and give me the plan ordered by regulatory risk rather than by engineering convenience", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "september release is fixed and the audio team has six weeks minus two for QA, with six candidate items ranging from a day's rounding fix to restructuring who owns plugin state. sequence them for me with the dropout problem as the priority, and be explicit about which items i should cut rather than half-finish", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "operators configure the build agent from flag help alone, which is why one customer ran with fast-path on for a year without knowing what it meant. write the configuration guide, covering what each option does, which combinations are dangerous, and the fact that the reaper is the only thing that recovers a leaked slot some of them run us on hardware we've never seen, so avoid assuming our own topology.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "support explains the plugin blocklist several times a week and users reinstall plugins that were never the problem. write the help article that explains what the scan does, why a plugin disappears, and how to bring it back — pitched at a musician rather than an engineer, and without making our crash handling sound like a defect the article should stand alone without requiring a terminal, if that's at all possible.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether our ring buffer is genuinely safe given that it carries std::function objects the audio thread invokes, and the copy on push may allocate. read it carefully and tell me exactly which operations can allocate or block, and whether the memory ordering is right for the single-producer single-consumer use we actually have", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "scheduler reserves slots in memory and dispatches in a goroutine that can take thirty seconds, while agents may already be running work accepted from a previous scheduler instance. work through what happens across a scheduler restart and tell me whether double-assignment is possible, and if so how often it would show up as the wedging we see", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "claims API is integrated by four brokers off a spreadsheet, and the two things they get wrong every time are the 202 response and the 24-hour deduplication window. write the reference documentation properly, structured so those two are impossible to miss, with a worked example of a submission and its follow-up polling assume the reader is integrating for the first time and has our sandbox credentials.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "parameter smoothing is implemented four times across our processors, three of them sample-rate dependent in ways the authors probably didn't intend, and only one resets properly on prepareToPlay. consolidate onto one implementation with an explicit time constant, and keep each processor's audible behaviour at 48kHz indistinguishable from today's the reverb is the reference implementation as far as anyone remembers.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "step status exists as an int in the agent, a string in the API and a smallint in the database, with three switch statements mapping between them and one missing case that silently reports \"queued\". unify on one representation, handle the two legacy values that exist in production rows, and keep the public API strings exactly as they are there are two production rows with values five and six that predate the current enum.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "before the audio work starts i want the threading model written down properly — what the audio thread may touch, how state gets to it, what the message thread owns — and then the plugin scanner moved off the shared lock as the first piece of evidence that the model works the scanner is the piece we can ship first, and the release is in six weeks.", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "workspace isolation needs a decision and also needs progress. lay out the options with their build-time cost, then implement per-job workspaces behind a flag so we can measure the real impact rather than argue about the naive experiment the naive experiment's forty percent slowdown is the number everyone will quote at us.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "rating reproducibility is a february problem that needs starting now. give me the design — what we record, how the engine is versioned, what re-rating means — and then the rating_runs table and write path so new ratings start being recorded while the rest is designed the regulator's wording is about the life of the claim plus seven years, not about our schema.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "die Session-Datei ist inzwischen 80 MB groß und blockiert beim Laden den Message-Thread. Ich hätte gern zuerst ein Konzept für inkrementelles Laden und danach die Umsetzung des Track-Lazy-Loadings, damit die Startzeit vor dem Release besser wird", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "de"}
{"prompt": "webhook receiver needs to stop dropping events during the insurer's morning batch, and the fix probably changes our whole ingestion shape. think through the design — accept fast, persist cheaply, order per policy — then implement the accept path so tomorrow's batch survives their batch starts at six and they retry anything that isn't a 200 for a full day.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "agent configuration guide needs writing, and while going through the flags i expect you'll find at least one whose documented default doesn't match the binary. produce the guide, and list every discrepancy you find between help text and behaviour operators run this on hardware we've never seen, so defaults matter more than usual.", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la documentación de la API de siniestros para los corredores y comprueba en el código si la deduplicación de 24 horas funciona como decimos, porque uno de ellos dice que recibe referencias distintas", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "wedged-agent runbook should be a page rather than folklore, and the underlying non-idempotent slot release should stop being a footnote. write the runbook, then make release idempotent so the runbook's main entry becomes unnecessary the non-idempotent release has been a known footnote for months and it keeps costing us nights.", "purpose": "writing", "secondary": "backendImpl", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "plugin state lives in three places kept in sync by callbacks, two of which the audio thread reads. give it one owner, and write the short note explaining the new ownership so the next person doesn't add a fourth copy two of the three copies are read on the audio thread, which is the part that frightens me.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "automation recorder calls host APIs from the audio thread, which explains the segfaults, but i want that confirmed before we restructure it. diagnose it properly, then move the parameter updates onto the message thread without changing the recorded result", "purpose": "debugging", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "MIDI events drift by about a third of a millisecond per thousand events, which smells like accumulated rounding in the sample conversion. confirm the mechanism, then fix the scheduling so long sessions stay accurate, and tell me whether existing sessions need anything", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "queue alerts page for the normal morning batch and stayed silent through a six-hour genuine backlog. work out what the rules should be from the actual traffic pattern, then change them", "purpose": "quickFix", "secondary": "planning", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "agents should register with short-lived credentials rather than the long-lived token baked into user data. design the enrolment flow, then implement the token exchange", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "audio engine's parameter classes each reimplement denormal protection, three of them slightly wrong", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "go services each parse their own config with a different precedence between flags, env and file", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "rename `StepState` to `StepPhase` in the agent, it's confused with the API's status everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain what happens to a running build when the scheduler restarts", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "why does our cache key not include the container image, and has that ever bitten us", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "someone should check whether a broker can reach another broker's documents by guessing an id", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that a step's secrets are visible to every command in that step", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "docs/rating.md describes a synchronous rating call that we made asynchronous last year", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "SDK header comments claim processBlock may allocate \"if necessary\", which is precisely wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "write the migration note for operators about the minimum macOS version change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "precisamos de uma página que explique aos corretores como funciona a atribuição automática", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "pt"}
{"prompt": "scan timeout counts as a crash toward the blocklist, which nobody intended", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "how should we version the pipeline YAML format now that we need to change three of its behaviours", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "what's the right approach to testing audio code where the failure mode is an audible glitch", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "three brokers want webhooks from us and we've only ever consumed them, what should our outbound story be", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to in-flight builds when a customer's plan is downgraded mid-pipeline", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns a step's log with byte-range support, for the viewer's infinite scroll", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "claim documents should be served through signed URLs that expire, rather than proxied through rails", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "per-broker rate limits on the claims API, since one broker's batch job saturates our workers", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "session file should record the host sample rate so we can warn on mismatch at load", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "log viewer needs to follow output without pinning the scroll when the user has scrolled up", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "pipeline graph should collapse matrix expansions into one node with a count", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "documents grid needs a drag-to-upload target that works on the whole panel", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "stem export needs a naming template field with a live preview of the resulting filenames", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "whichever is least risky today", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick up the scanner work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "our go services each parse configuration with a different precedence between flags, environment variables and the config file, and two of them silently ignore the file when a flag is present. settle on one precedence, apply it across all four services, and tell me which deployed configurations would resolve differently afterwards so we can warn the operators who run them", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a broker's support ticket claims they can see a document that isn't theirs, which if true is the worst bug we could have. before anyone panics, trace how document authorisation actually works — the controller, the signed URL, and whether the scan-moved key is checked against the claim's broker at all", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "we need per-broker rate limiting on the claims API, because one broker's nightly batch job saturates the worker pool and everyone else's submissions queue behind it. limits per broker with a burst allowance, a clear 429 with a retry-after, and the limits themselves configurable without a deploy since account managers negotiate them individually", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "the claims models carry twelve callbacks whose firing order is load-bearing, which is why nobody dares add a thirteenth. untangle them into explicit service calls, keep the observable behaviour identical including the side effects on save, and document the order the old callbacks ran in so we can prove nothing was lost", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "denormal protection is reimplemented in each parameter class and three of the four are subtly wrong, which we only noticed because one processor gets slower with quiet input. consolidate it, and confirm from measurements rather than reasoning that the CPU behaviour is unchanged on the processors that were already correct", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like an honest read of whether our audit log can be altered by the admins it's meant to hold accountable, and if it can, the smallest change that fixes it before february rather than the ideal one", "purpose": "review", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "prod agents run eight slots on eight cores, which is why steps time out instead of queueing, and the fix is a number in a config file. change it, and tell me what else in the agent's defaults assumes a machine larger than the one it runs on", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt":"HinterlandMicaProfileCoordinator needs a paired pass: assess ownership and failure handling in projects/hinterland/workers/thumbnail/consumer.ex, plus capture the contract and rollback note for consumers. Use projects/hinterland/workers/thumbnail/consumer.ex as the source of truth, preserve the Playwright contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-48127: retire the legacy replay path for HinterlandDeltaCanvasFlow\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 HinterlandDeltaCanvasFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/hinterland/src/sync/reconcile.ts: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: hinterlanddriftconsoleflow::scheduler::LeaseTask::flush\n at ./projects/hinterland/src/sync/reconcile.ts:217:18\n 4: hinterlanddriftconsoleflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nFind the source of this HinterlandDriftConsoleFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Clarify HinterlandPrismCacheService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Dashboard: # projects/hinterland/crates/index/src/segment.rs\n[worker.hinterlandwillowcodecflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandwillowcodecflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandwillowcodecflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandWillowCodecFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48140\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/hinterland/crates/index/src/segment.rs and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Corrige le timeout de HinterlandDeltaCanvasStore","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"fr"}
{"prompt":"En projects/hinterland/workers/thumbnail/consumer.ex, HinterlandBeaconStoreService tiene un problema intermitente en el flujo de Playwright. Redacta una guía para consumidores con contrato, errores, retry y un ejemplo copiable; no cambies el handler.\n\nRestricciones:\n- seguir con Playwright\n- conservar compatibilidad y cancelación\n- limitar el cambio a HinterlandBeaconStoreService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"es"}
{"prompt":"Worker: # projects/hinterland/workers/thumbnail/consumer.ex\n[worker.hinterlandnovapickerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandnovapickerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandnovapickerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandNovaPickerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48123\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 HinterlandNovaPickerFlow'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":"Simulator: # projects/hinterland/ui/settings/PrivacyPane.tsx\n[worker.hinterlandmicaprofileflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandmicaprofileflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandmicaprofileflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandMicaProfileFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48133\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/hinterland/ui/settings/PrivacyPane.tsx. 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":"Runbook: projects/hinterland/packages/api/openapi.yaml 里的 HinterlandLumenChartService 最近在 Redis Streams 流程中出现间歇性问题。 请给出阶段、兼容层、指标、rollback 和 ownership，先不要修改代码。\n\n约束：\n- 继续使用 Redis Streams\n- 保持兼容性和取消语义\n- 改动只限于 HinterlandLumenChartService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"The minimum supported React 19 version in projects/hinterland/Sources/CLI/Commands/Doctor.swift is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Wire a HinterlandQuartzPlayerFlow background task in projects/hinterland/app/src/main/SyncWorker.kt that expires abandoned sessions, records an OpenTelemetry span, and yields cleanly when shutdown begins.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two asks around HinterlandSableParserCoordinator: (1) assess ownership and failure handling in projects/hinterland/Sources/App/SessionStore.swift; (2) capture the contract and rollback note for consumers. Avoid a schema migration in this release, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"HinterlandEchoRegistryCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"HinterlandWillowCodecCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"HinterlandCinderAuthCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Could HinterlandFlintTimelineService migrate incrementally?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"Sketch the HinterlandCopperBridgeService migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Design handed over a final pass for HinterlandWrenExportService, and the basic data flow in projects/hinterland/config/staging.toml already works. 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- avoid a schema migration in this release\n- stay compatible with the existing Redis Streams deployment\n- keep the work scoped to HinterlandWrenExportService and its direct tests\n\nSeveral teams work in this search, Terraform, Flutter 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":"Test Suite 'HinterlandSlateEditorCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[HinterlandSlateEditorCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/hinterland/services/ledger/replay.go:144: error: -[HinterlandSlateEditorCoordinatorTests 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 '-[HinterlandSlateEditorCoordinatorTests 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 HinterlandSlateEditorCoordinator's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Support wants the behavior in projects/hinterland/apps/console/routes/usage.svelte 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":"Is HinterlandRavenSessionStore safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"HinterlandLedgerGateCoordinator is blocking the next release because lease renewal code copied across three workers. I need two concrete outcomes from a single pass: produce a consumer guide for HinterlandLedgerGateCoordinator, and give the existing implementation a read-only safety pass. Use the existing React 19 conventions in projects/hinterland/cmd/exporter/main.py; avoid a schema migration in this release. 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":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Trace: # projects/hinterland/db/migrations/20260730_events.sql\n[worker.hinterlandflinttimelineflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandflinttimelineflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandflinttimelineflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandFlintTimelineFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48132\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 HinterlandFlintTimelineFlow'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":"Responsive layout for HinterlandNimbusFormStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"For HinterlandPrismCacheCoordinator, lay out a staged migration for HinterlandPrismCacheCoordinator; once that is complete, then implement the bounded durable-cursor handler. Work from projects/hinterland/packages/api/openapi.yaml, stay with Redis Streams, and avoid a schema migration in this release. Keep the two outcomes separately reviewable.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Extract HinterlandAsterWebhookStore's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Outline a safer HinterlandGarnetModalService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"HinterlandSlateEditorService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current Terraform operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Does HinterlandIrisBatchStore 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.6,"slice":"core","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_48135'\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_48135'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nWire HinterlandLumenChartFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating two validators with subtly different error strings in HinterlandBirchMigratorService, 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":"Give HinterlandFlintTimelineStore a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Style HinterlandMoonlitSDKService's offline state","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/hinterland/ui/settings/PrivacyPane.tsx b/projects/hinterland/ui/settings/PrivacyPane.tsx\nindex 62d71aa..90f3c1e 100644\n--- a/projects/hinterland/ui/settings/PrivacyPane.tsx\n+++ b/projects/hinterland/ui/settings/PrivacyPane.tsx\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Read the artifact above as a skeptical reviewer. Is HinterlandPineMetricsFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Two engineers disagree about whether HinterlandWrenExportStore's cache is authoritative. Walk the reads and writes in projects/hinterland/packages/api/openapi.yaml and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"We need to move HinterlandWillowCodecService from the legacy store to Redis Streams. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Why is HinterlandMicaProfileService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"HinterlandNovaPickerCoordinator: polish, then document","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"// projects/hinterland/services/ledger/replay.go\nfinal class HinterlandEmberRelayFlowCoordinator {\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 HinterlandEmberRelayFlow; 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":"projects/hinterland/Sources/CLI/Commands/Doctor.swift now contains HinterlandMarbleTokenService's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The destination for HinterlandFernSnapshotService is broadly agreed; the missing piece is a reversible route from projects/hinterland/pkg/cache/lease.rs to that target. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandFernSnapshotService\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-48125: retire the legacy replay path for HinterlandPrismCacheFlow\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 HinterlandPrismCacheFlow 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":"HinterlandSableParserService's Doctor.swift needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Diff: The public surface of HinterlandPineMetricsService is frozen, but its internal ownership in projects/hinterland/ui/settings/PrivacyPane.tsx is difficult to test and even harder to change safely. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandPineMetricsService\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"HinterlandBirchMigratorCoordinator: rethink this area","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ownership of HinterlandIrisBatchService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current Redis Streams operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Profiler: // projects/hinterland/Sources/App/SessionStore.swift\nfinal class HinterlandBirchMigratorFlowCoordinator {\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 HinterlandBirchMigratorFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Could the reasoning behind HinterlandDriftConsoleService's Core Data choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Console: Ticket OPS-48119: retire the legacy replay path for HinterlandCloudReconcilerFlow\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 HinterlandCloudReconcilerFlow 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":"Workspace: diff --git a/projects/hinterland/ui/settings/PrivacyPane.tsx b/projects/hinterland/ui/settings/PrivacyPane.tsx\nindex 62d71aa..90f3c1e 100644\n--- a/projects/hinterland/ui/settings/PrivacyPane.tsx\n+++ b/projects/hinterland/ui/settings/PrivacyPane.tsx\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\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Wire HinterlandBeaconStoreCoordinator's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"HinterlandHarborIndexStore is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current React 19 operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Repository: Could the reasoning behind HinterlandWillowCodecStore's Redis Streams choices be captured as an ADR for engineers joining the project next quarter? 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":"Assess the HinterlandCedarPolicyService diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"We need to move HinterlandAcornWidgetFlow from the legacy store to React 19. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Move HinterlandEchoRegistryStore'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":"Pipeline: // projects/hinterland/Sources/App/SessionStore.swift\nfinal class HinterlandHarborIndexFlowCoordinator {\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 HinterlandHarborIndexFlow 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":"HinterlandMapleQueueCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"PM is preparing the HinterlandCedarPolicyStore rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandCedarPolicyStore\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; 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":"Find HinterlandCraneWorkspaceService's duplicate retry source","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Gateway: diff --git a/projects/hinterland/ml/pipeline/features.py b/projects/hinterland/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/hinterland/ml/pipeline/features.py\n+++ b/projects/hinterland/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is HinterlandRavenSessionFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"HinterlandVelaDrawerCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"I inherited HinterlandRainfallDBStore and need a careful read of projects/hinterland/config/staging.toml before I can sign off on the next release. 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- avoid a schema migration in this release\n- stay compatible with the existing Redis Streams deployment\n- keep the work scoped to HinterlandRainfallDBStore and its direct tests\n\nSeveral teams work in this search, Terraform, Flutter monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"HinterlandAtlasSearchService'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":"Split HinterlandAsterWebhookService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Renderer: // projects/hinterland/db/migrations/20260730_events.sql\nfinal class HinterlandJuniperCLIFlowCoordinator {\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 HinterlandJuniperCLIFlow 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, HinterlandOrbitSyncService has shown duplicate retries after a network handoff; nobody on the team can reproduce it reliably on a laptop. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- avoid a schema migration in this release\n- stay compatible with the existing Core Data deployment\n- keep the work scoped to HinterlandOrbitSyncService and its direct tests\n\nSeveral teams work in this search, Terraform, Flutter monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-48138\n\n08:02 deploy HinterlandBasilRunnerFlow 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 HinterlandBasilRunnerFlow, 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":"Indexer: diff --git a/projects/hinterland/apps/console/routes/usage.svelte b/projects/hinterland/apps/console/routes/usage.svelte\nindex 62d71aa..90f3c1e 100644\n--- a/projects/hinterland/apps/console/routes/usage.svelte\n+++ b/projects/hinterland/apps/console/routes/usage.svelte\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate HinterlandCopperBridgeFlow'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":"HinterlandBasilRunnerCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"HinterlandOspreyJobCoordinator needs a paired pass: separate HinterlandOspreyJobCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/hinterland/internal/auth/refresh.go as the source of truth, preserve the Terraform contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Release engineering needs a HinterlandDriftConsoleStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition. 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":"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_48151'\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_48151'::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\nFind the source of this HinterlandAmberFilterCoordinator symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Sequence HinterlandOspreyJobStore's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Investigate the HinterlandOspreyJobService hang","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Apparently: projects/hinterland/workers/thumbnail/consumer.ex の HinterlandMapleQueueService で、Playwright の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- Playwright を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は HinterlandMapleQueueService のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"ja"}
{"prompt":"HinterlandAsterWebhookCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"HinterlandMarbleTokenCoordinator: handle the lingering thing","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-48118\n\n08:02 deploy HinterlandAsterWebhookFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the HinterlandAsterWebhookFlow 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":"Lately: Incident timeline — INC-48154\n\n08:02 deploy HinterlandCoralUploadCoordinator 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the HinterlandCoralUploadCoordinator 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":"HinterlandLumenChartCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"How does HinterlandEmberRelayStore propagate cancellation through the Terraform boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Oddly: Incident timeline — INC-48146\n\n08:02 deploy HinterlandMarbleTokenFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why HinterlandMarbleTokenFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Translate the HinterlandMoonlitSDKStore setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"For HinterlandRavenSessionCoordinator, separate HinterlandRavenSessionCoordinator's policy from transport without behavior changes; once that is complete, capture the contract and rollback note for consumers. Work from projects/hinterland/cmd/exporter/main.py, stay with React 19, and avoid a schema migration in this release. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"HinterlandKiteSchedulerCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Currently: projects/hinterland/ui/settings/PrivacyPane.tsx 里的 HinterlandMapleQueueStore 最近在 Playwright 流程中出现间歇性问题。 请追踪 queue、scheduler 和取消路径，对比假设，先定位原因再提修改。\n\n约束：\n- 继续使用 Playwright\n- 保持兼容性和取消语义\n- 改动只限于 HinterlandMapleQueueStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Today: // projects/hinterland/apps/console/routes/usage.svelte\nfinal class HinterlandQuartzPlayerCoordinatorCoordinator {\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 HinterlandQuartzPlayerCoordinator; 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":"Context: # projects/hinterland/Sources/CLI/Commands/Doctor.swift\n[worker.hinterlandsableparserflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandsableparserflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandsableparserflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandSableParserFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48126\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 HinterlandSableParserFlow'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":"projects/hinterland/crates/index/src/segment.rs now contains HinterlandIrisBatchFlow's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current HinterlandAmberFilterService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandAmberFilterService\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"The data is already available in projects/hinterland/lib/codec/frame.cc; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Background: Incident timeline — INC-48122\n\n08:02 deploy HinterlandOpalRouterFlow 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 HinterlandOpalRouterFlow 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":"How does HinterlandVelaDrawerStore propagate cancellation through the Redis Streams boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"I inherited HinterlandFrostPanelService and need a careful read of projects/hinterland/engine/render/atlas.cpp before I can sign off on the next release. 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- avoid a schema migration in this release\n- stay compatible with the existing Playwright deployment\n- keep the work scoped to HinterlandFrostPanelService and its direct tests\n\nSeveral teams work in this search, Terraform, Flutter monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Move HinterlandSpruceDaemonService's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Could HinterlandCoralUploadStore show the active Terraform sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"HinterlandSpruceDaemonCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current HinterlandCopperBridgeStore design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandCopperBridgeStore\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"# projects/hinterland/ml/pipeline/features.py\n[worker.hinterlandledgergateflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandledgergateflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandledgergateflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandLedgerGateFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48111\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 HinterlandLedgerGateFlow'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":"Read projects/hinterland/engine/render/atlas.cpp and tell me whether HinterlandBasilRunnerStore can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-48124: finish the compact HinterlandOspreyJobFlow filter experience\n\nRoute: /catalog/search\nSource: projects/hinterland/infra/modules/edge/main.tf\nFramework: Terraform\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\nBring HinterlandOspreyJobFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"HinterlandMosaicGridCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new HinterlandSpruceDaemonStore 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":"Center the HinterlandNovaPickerStore modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"For HinterlandGarnetModalCoordinator, separate HinterlandGarnetModalCoordinator's policy from transport without behavior changes; once that is complete, capture the contract and rollback note for consumers. Work from projects/hinterland/lib/codec/frame.cc, stay with Playwright, and avoid a schema migration in this release. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"HinterlandCopperBridgeCoordinator: sequence, then restructure","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Two deliverables are holding up HinterlandJuniperCLICoordinator. First, finish HinterlandJuniperCLICoordinator's responsive empty and retry states. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/hinterland/src/sync/reconcile.ts, which follows Core Data conventions and currently suffers from duplicate retries after a network handoff. Avoid a schema migration in this release.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"# CI job 48121: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: React 19\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] HinterlandTideWorkerFlowIntegration.replays_after_timeout ... ok\n[test] HinterlandTideWorkerFlowIntegration.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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Add the bounded HinterlandTideWorkerFlow 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":"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_48137'\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_48137'::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\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Determine why HinterlandSpruceDaemonFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Collapse the HinterlandOpalRouterService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Describe HinterlandOpalRouterStore's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for HinterlandFernSnapshotCoordinator:\n- primary outcome: finish HinterlandFernSnapshotCoordinator's responsive empty and retry states\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/hinterland/crates/index/src/segment.rs\n- platform constraint: Redis Streams\n- known complication: an accessibility label that reads the internal enum\n\nBoth results are required, but they should remain independently reviewable. Avoid a schema migration in this release; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"A copied hex color in HinterlandWrenExportFlow lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"HinterlandAcornWidgetService needs a production server path for replaying tenant events; the public envelope is agreed but persistence and retry handling are not wired. 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- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current React 19 operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-48144: retire the legacy replay path for HinterlandKiteSchedulerFlow\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 HinterlandKiteSchedulerFlow 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":"Does HinterlandBasilRunnerService 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.4,"slice":"core","lang":"en"}
{"prompt":"The minimum supported Terraform version in projects/hinterland/infra/modules/edge/main.tf 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":"Flip HinterlandTideWorkerService's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"A copied hex color in HinterlandEmberRelayService lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Cadre la migration de HinterlandCloudReconcilerService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"fr"}
{"prompt":"Ticket OPS-48129: retire the legacy replay path for HinterlandMoonlitSDKFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. From this evidence, draft consumer-facing migration guidance for HinterlandMoonlitSDKFlow, 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":"HinterlandAtlasSearchCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'HinterlandWrenExportCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[HinterlandWrenExportCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/hinterland/packages/api/openapi.yaml:144: error: -[HinterlandWrenExportCoordinatorTests 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 '-[HinterlandWrenExportCoordinatorTests 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\nFinish the visible HinterlandWrenExportCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Question: The next client release depends on a new HinterlandSlateEditorStore capability in projects/hinterland/services/ledger/replay.go, with Terraform already chosen by the platform group. Wire the schema, repository, handler, and worker so duplicate deliveries return the original result and shutdown never acknowledges uncommitted work.\n\nConstraints:\n- avoid a schema migration in this release\n- stay compatible with the existing Terraform deployment\n- keep the work scoped to HinterlandSlateEditorStore and its direct tests\n\nSeveral teams work in this search, Terraform, Flutter monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe contract notes are context; the requested outcome is the working server path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"HinterlandEmberRelayCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"This should remain a deliberately small patch: HinterlandJuniperCLIStore has one known configuration mistake in projects/hinterland/src/sync/reconcile.ts, not an open-ended failure investigation. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- avoid a schema migration in this release\n- stay compatible with the existing Core Data deployment\n- keep the work scoped to HinterlandJuniperCLIStore and its direct tests\n\nSeveral teams work in this search, Terraform, Flutter monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Collapse the HinterlandNimbusFormService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a HinterlandAcornWidgetStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Move HinterlandBeaconStoreFlow's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Observation: Move HinterlandTideWorkerStore behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Two asks around HinterlandFlintTimelineCoordinator: (1) assess ownership and failure handling in projects/hinterland/src/sync/reconcile.ts; (2) capture the contract and rollback note for consumers. Avoid a schema migration in this release, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Constraint: // projects/hinterland/db/migrations/20260730_events.sql\nfinal class HinterlandOrbitSyncCoordinatorCoordinator {\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\nDeliver the HinterlandOrbitSyncCoordinator 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":"HinterlandCloudReconcilerCoordinator: sequence, then ship","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"HinterlandOpalRouterCoordinator: ship, then correct","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"vague-eval","lang":"en"}
{"prompt":"Remove HinterlandGarnetModalStore's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Request: # projects/hinterland/Sources/App/SessionStore.swift\n[worker.hinterlandacornwidgetcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandacornwidgetcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandacornwidgetcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandAcornWidgetCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48156\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 HinterlandAcornWidgetCoordinator'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":"Split projects/hinterland/apps/console/routes/usage.svelte by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Vereinheitliche die HinterlandCloudReconcilerStore-Validatoren","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"# projects/hinterland/engine/render/atlas.cpp\n[worker.hinterlandgarnetmodalflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandgarnetmodalflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandgarnetmodalflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandGarnetModalFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48128\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/hinterland/engine/render/atlas.cpp and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"HinterlandNimbusFormCoordinator needs a paired pass: separate HinterlandNimbusFormCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/hinterland/crates/index/src/segment.rs as the source of truth, preserve the Redis Streams contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"$ pnpm test --filter HinterlandSummitProxyFlow\n RUN v3.2.4 /workspace/apps/console\n × HinterlandSummitProxyFlow > 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=48147 phase=resume storedCursor=seg-0183\n session=48147 phase=fetch requestCursor=seg-0183 pageSize=200\n session=48147 phase=commit receivedCursor=seg-0184 itemCount=0\n session=48147 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the HinterlandSummitProxyFlow 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":"Find HinterlandSableParserStore's duplicate retry source","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"HinterlandSummitProxyCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Fresh release brief for HinterlandPineMetricsCoordinator:\n- primary outcome: produce a consumer guide for HinterlandPineMetricsCoordinator\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/hinterland/workers/thumbnail/consumer.ex\n- platform constraint: Playwright\n- known complication: a query plan that changes after statistics refresh\n\nBoth results are required, but they should remain independently reviewable. Avoid a schema migration in this release; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Please turn HinterlandAmberFilterStore's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The data is already available in projects/hinterland/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":"Polish the HinterlandNovaPickerService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a misleading timeout name used in five packages in HinterlandOrbitSyncFlow, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Goal: Ticket OPS-48149: retire the legacy replay path for HinterlandAtlasSearchFlow\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 HinterlandAtlasSearchFlow 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":"HinterlandHarborIndexCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Symptom: The name pendingAck means two different things across HinterlandFrostPanelFlow's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Where did HinterlandCraneWorkspaceStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current HinterlandQuartzPlayerService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandQuartzPlayerService\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Persist HinterlandAtlasSearchStore delivery attempts in projects/hinterland/services/ledger/replay.go, claim them safely across workers, and make duplicate webhook receipts return the original accepted result.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"// projects/hinterland/crates/index/src/segment.rs\nfinal class HinterlandCraneWorkspaceFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate HinterlandCraneWorkspaceFlow'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":"Polish the HinterlandRavenSessionService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Headsup: A flaky failure around HinterlandCoralUploadService survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandCoralUploadService\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"FYI: // projects/hinterland/internal/auth/refresh.go\nfinal class HinterlandCinderAuthFlowCoordinator {\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 HinterlandCinderAuthFlow 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":"Meanwhile: A copied hex color in HinterlandVelaDrawerService lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"HinterlandRainfallDBService flakes under UTC","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Describe HinterlandHarborIndexService's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"HinterlandCinderAuthService's staging timeout is already known to be wrong: change the single projects/hinterland/internal/auth/refresh.go value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Move HinterlandSlateEditorFlow'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":"2026-07-30T08:14:11.409Z level=info service=hinterlandmosaicgridflow pod=hinterlandmosaicgridflow-7cf8 request_id=48148 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=hinterlandmosaicgridflow request_id=48148 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=hinterlandmosaicgridflow request_id=48148 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=hinterlandmosaicgridflow request_id=48148 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=hinterlandmosaicgridflow request_id=48148 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=hinterlandmosaicgridflow request_id=48148 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=hinterlandmosaicgridflow request_id=48148 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=hinterlandmosaicgridflow request_id=48148 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\nFind the source of this HinterlandMosaicGridFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"How should HinterlandPrismCacheStore be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"HinterlandCraneWorkspaceCoordinator: sequence, then restructure","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Locally: # projects/hinterland/internal/auth/refresh.go\n[worker.hinterlandcedarpolicyflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandcedarpolicyflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandcedarpolicyflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandCedarPolicyFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48114\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 HinterlandCedarPolicyFlow'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":"Read projects/hinterland/internal/auth/refresh.go and tell me whether HinterlandKiteSchedulerStore 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":"HinterlandTideWorkerCoordinator: sequence, then polish","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-48110\n\n08:02 deploy HinterlandFernSnapshotFlow 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 HinterlandFernSnapshotFlow 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":"Test Suite 'HinterlandMapleQueueFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[HinterlandMapleQueueFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/hinterland/workers/thumbnail/consumer.ex:144: error: -[HinterlandMapleQueueFlowTests 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 '-[HinterlandMapleQueueFlowTests 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\nFinish the visible HinterlandMapleQueueFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"One contained cleanup in projects/hinterland/cmd/exporter/main.py: remove the obsolete HinterlandEchoRegistryService import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"What is the safest way to split projects/hinterland/app/src/main/SyncWorker.kt into independently owned modules while HinterlandSummitProxyService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"Test Suite 'HinterlandEchoRegistryFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[HinterlandEchoRegistryFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/hinterland/cmd/exporter/main.py:144: error: -[HinterlandEchoRegistryFlowTests 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 '-[HinterlandEchoRegistryFlowTests 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 HinterlandEchoRegistryFlow'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":"The HinterlandCinderAuthStore 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":"Could HinterlandMosaicGridService show the active Playwright sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Is there a cleaner way to separate HinterlandBeaconStoreStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"En projects/hinterland/cmd/exporter/main.py, HinterlandLedgerGateStore tiene un problema intermitente en el flujo de React 19. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con React 19\n- conservar compatibilidad y cancelación\n- limitar el cambio a HinterlandLedgerGateStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con React 19 alrededor de HinterlandLedgerGateStore.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"es"}
{"prompt":"Three teams extended HinterlandPineMetricsStore independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current Playwright operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"HinterlandCedarPolicyCoordinator is blocking the next release because two validators with subtly different error strings. I need two concrete outcomes from a single pass: lay out a staged migration for HinterlandCedarPolicyCoordinator, and consolidate the duplicated normalization paths without changing behavior. Use the existing Terraform conventions in projects/hinterland/infra/modules/edge/main.tf; avoid a schema migration in this release. 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":"planning","secondary":"refactor","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Two deliverables are holding up HinterlandRainfallDBCoordinator. First, produce a consumer guide for HinterlandRainfallDBCoordinator. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/hinterland/config/staging.toml, which follows Redis Streams conventions and currently suffers from memory growth during hour-long imports. Avoid a schema migration in this release.\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":"writing","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Em projects/hinterland/config/staging.toml, o HinterlandLumenChartStore tem um problema intermitente no fluxo de Redis Streams. Siga queue, scheduler e cancelamento, compare hipóteses e encontre a causa antes de mudar código.\n\nRestrições:\n- continuar com Redis Streams\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao HinterlandLumenChartStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"pt"}
{"prompt":"Two asks around HinterlandMoonlitSDKCoordinator: (1) assess ownership and failure handling in projects/hinterland/services/ledger/replay.go; (2) capture the contract and rollback note for consumers. Avoid a schema migration in this release, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Drop HinterlandMicaProfileStore's unused import","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-48130\n\n08:02 deploy HinterlandNimbusFormFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the HinterlandNimbusFormFlow 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":"HinterlandDriftConsoleCoordinator: sort out the rough edge","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Production: // projects/hinterland/packages/api/openapi.yaml\nfinal class HinterlandRainfallDBFlowCoordinator {\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 HinterlandRainfallDBFlow; 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":"Staging: # projects/hinterland/lib/codec/frame.cc\n[worker.hinterlandfrostpanelcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.hinterlandfrostpanelcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.hinterlandfrostpanelcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.HinterlandFrostPanelCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-48158\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/hinterland/lib/codec/frame.cc and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"HinterlandFernSnapshotStore is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current Redis Streams operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"// projects/hinterland/config/staging.toml\nfinal class HinterlandVelaDrawerFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Walk through what the artifact proves about HinterlandVelaDrawerFlow; 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":"HinterlandDeltaCanvasCoordinator needs a paired pass: change HinterlandDeltaCanvasCoordinator's known staging timeout from 15 to 30 seconds, plus give the existing implementation a read-only safety pass. Use projects/hinterland/apps/console/routes/usage.svelte as the source of truth, preserve the Core Data contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"CI: The behavior of HinterlandJuniperCLIService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/hinterland/db/migrations/20260730_events.sql. 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- touch generated artifacts only through their checked-in generator\n- avoid a schema migration in this release\n- retain the current Core Data operational envelope\n\nThe relevant code crosses search, Terraform, Flutter. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"PM needs a concise migration note for HinterlandOrbitSyncStore, 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":"Nobody is asking for code changes yet; we first need to understand whether the current HinterlandFrostPanelStore design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside HinterlandFrostPanelStore\n- avoid a schema migration in this release\n\nThis repository spans search, Terraform, Flutter; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Documente o contrato de HinterlandDeltaCanvasService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"The name pendingAck means two different things across HinterlandMarbleTokenStore's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Atlas: projects/hinterland/cmd/exporter/main.py の HinterlandAmberFilterFlow で、React 19 の flow に断続的な問題が起きています。 queue、scheduler、cancel 経路を追い、仮説を比較して、変更前に原因を特定してください。\n\n制約:\n- React 19 を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は HinterlandAmberFilterFlow のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"In projects/hinterland/ml/pipeline/features.py hat HinterlandLedgerGateService ein sporadisches Problem im React 19-Ablauf. Verfolge Queue, Scheduler und Abbruch, vergleiche Hypothesen und finde die Ursache vor jeder Änderung.\n\nRandbedingungen:\n- React 19 weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf HinterlandLedgerGateService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um HinterlandLedgerGateService mit React 19 kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"de"}
{"prompt":"Beacon: Incident timeline — INC-48150\n\n08:02 deploy HinterlandIrisBatchCoordinator 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 HinterlandIrisBatchCoordinator 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"}
data/round2-09.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "the exam thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "our staging kafka has one partition and prod has twelve, which is why ordering bugs never show up first", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "attempt state machine is spread across four files as boolean columns and ad-hoc checks:\n\nattempt.startedAt // set on create\nattempt.submittedAt // set on submit, also set by the nightly auto-submit job\nattempt.gradedAt // set by the grading worker\nattempt.voidedAt // set by support scripts only\nattempt.mergedIntoId // set by the merge script, and the old attempt keeps its submittedAt\n\nchecks like `if (attempt.submittedAt && !attempt.gradedAt)` appear in eleven places, three of which forget voidedAt, and the review screen's definition of \"latest attempt\" is different again", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "one grading calculation, three call sites", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "our exam load is 40,000 concurrent students for two hours twice a year and idle the rest of the time", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "the WMS has two definitions of \"aisle available\" — the dispatcher's, which asks whether any robot could enter, and the console's, which asks whether a human could — and during maintenance they disagree in the dangerous direction. reconcile them into one predicate with an explicit meaning, keep the console's display identical for the normal case, and tell me which existing callers change behaviour", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "quiz submissions vanish for a handful of students each exam and this is all we get:\n\nPrismaClientKnownRequestError:\nInvalid `prisma.submission.create()` invocation:\n\nUnique constraint failed on the fields: (`attemptId`,`questionId`)\n at RequestHandler.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:121:6412)\n at async POST (/app/app/api/attempts/[id]/answers/route.ts:41:22)\n\n attemptId: 'atmp_01HR9K2M'\n questionId: 'q_88412'\n studentId: 'usr_4471'\n retryCount: 2\n clientTimestamp: 2026-07-29T11:02:14.881Z\n serverTimestamp: 2026-07-29T11:02:19.114Z\n\nthe client retries on a slow response, and the student sees their answer disappear from the review screen afterwards", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "detection rules stopped firing overnight and the pipeline claims everything is healthy:\n\n[ingest] 2026-07-29T02:00:04Z bulk index 8,412 docs into logs-edr-2026.07.29 took 412ms\n[ingest] 2026-07-29T02:00:09Z bulk index 8,118 docs took 388ms\n[rules] 2026-07-29T02:01:00Z executing 141 rules over window [01:56:00, 02:01:00]\n[rules] 2026-07-29T02:01:04Z 0 alerts generated (previous run: 22)\n[rules] 2026-07-29T02:06:00Z executing 141 rules over window [02:01:00, 02:06:00]\n[rules] 2026-07-29T02:06:03Z 0 alerts generated\n[ingest] 2026-07-29T02:07:11Z index logs-edr-2026.07.30 created\n\nthe index for tomorrow's date appearing at 02:07 is the only odd thing i can see, and our rules query `logs-edr-*` with a `@timestamp` range", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "robot cards should sort problems first", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "what counts as the latest attempt?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a district's procurement requires WCAG 2.2 AA conformance, per-student time extensions and a VPAT within six weeks, and we have none of those. i want the realistic plan: what we can genuinely fix, what we have to declare as a gap with a remediation date, and how we word a VPAT that is honest without losing the contract", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "one enrichment provider interface", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "attempt state as an enum, not five columns", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "task API is what the robot firmware integrates against, documented in a wiki page from 2023:\n\nGET /v1/tasks/next?robot_id=&capabilities=\n long-polls for up to 30 seconds; returns 204 when nothing is available\n a returned task is leased for 90 seconds and must be acked or it returns to the queue\nPOST /v1/tasks/{id}/ack { robot_id, accepted: bool, reason? }\nPOST /v1/tasks/{id}/progress { robot_id, node, percent }\nPOST /v1/tasks/{id}/complete { robot_id, outcome: \"done\"|\"failed\"|\"aborted\", detail? }\n completing a task that has already been requeued returns 409 and the robot must stop\n progress after the lease expires is accepted but ignored, which firmware treats as success\n\nwrite the integration reference; the lease semantics and the ignored-progress behaviour are what firmware keeps getting wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "three places compute a student's grade and they disagree in the third decimal:\n\n// app/lib/grades.ts — student view\nconst grade = assessments.reduce((sum, a) =>\n sum + Math.round(scoreFor(a) * 10) / 10 * a.weight, 0)\n\n// GradeService.java — teacher view\ntotal = total.add(s.getScore().multiply(a.getWeight())); // BigDecimal, rounded once at the end\n\n-- exports/grades.sql\nSELECT round(sum(s.score * a.weight)::numeric, 1) FROM ...\n\nthe teacher view is the one the institution treats as authoritative, and all three are visible to different users on the same day", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "rule engine has three ways to express the same condition and analysts use all of them:\n\n# style 1 — lucene string\nquery: 'event.code:5145 and winlog.event_data.ShareName:\"\\\\\\\\*\\\\IPC$\"'\n\n# style 2 — elasticsearch DSL, raw\nquery_dsl: { bool: { filter: [ { term: { \"event.code\": \"5145\" } } ] } }\n\n# style 3 — our own yaml shorthand, added last year\nmatch:\n event.code: 5145\n winlog.event_data.ShareName: \"*IPC$\"\n\nall three go through different code paths, only style 3 validates field names, and style 2 lets an analyst write a query that scans every index we have", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "is our tenant filter applied everywhere?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "exam week is three weeks away, lost answers are our most damaging bug, and the attempt model has assumptions in it that stopped being true when students started using two devices. i'd like the plan for what we change before exams and what we deliberately leave until after, with the risk of each decision written down so nobody relitigates it at midnight during the exam support has forty tickets from last term's exams if you want the failure patterns.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "we need a position on how the LMS syncs with student information systems, given opaque ids that change each academic year and a district that rate limits us to ten requests a second. design it, then implement the resumable sync loop so we can test against their sandbox their sandbox is available and their ids change every august, which is the awkward part.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "detection rule for lateral movement, which the security team says has too many false positives:\n\nname: Suspicious SMB session enumeration\nindex: logs-edr-*\nquery: |\n event.code:5145 and winlog.event_data.ShareName:\"\\\\\\\\*\\\\IPC$\"\n and winlog.event_data.RelativeTargetName:(\"srvsvc\" or \"wkssvc\" or \"samr\")\ninterval: 5m\nwindow: 5m\nthreshold:\n field: source.ip\n value: 10\nseverity: high\nsuppression: none\n\nfires about 40 times a day, almost always from the same six management servers, and nobody has tuned it since it was imported from a blog post", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "robot one, again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "a student's grade is computed three times in three languages and the three disagree in the third decimal, with the teacher's view treated as authoritative by the institution. consolidate onto that behaviour, keep the exports byte-identical where they already agree, and list every student whose displayed grade will change as a result the institution treats the teacher's view as authoritative and will not accept a change to it.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "quiz player has to survive exam conditions, which means an autosave state that never lies, a keyboard-operable navigator, a timer that doesn't shout every second, and a graceful fallback when javascript dies mid-exam. build it to the spec, and tell me which of those the current player gets wrong today forty thousand students sit exams in the same two-hour window twice a year.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "what does a bulk index rejection actually do to the events in that batch — are they lost or retried", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "inventory counts drift from reality by a few units a day and reconciliation can't explain it:\n\ntask 88401 PICK sku=SKU-4471 qty=3 from=A7-03-02 robot=R-041 status=COMPLETED at=11:02:14\ntask 88402 PICK sku=SKU-4471 qty=2 from=A7-03-02 robot=R-018 status=COMPLETED at=11:02:16\ninventory event sku=SKU-4471 location=A7-03-02 delta=-3 source=task-88401 at=11:02:19\ninventory event sku=SKU-4471 location=A7-03-02 delta=-2 source=task-88402 at=11:02:19\ncycle count sku=SKU-4471 location=A7-03-02 counted=4 system=2 at=18:00:00\n\nboth picks were dispatched from a snapshot showing 5 units, and the location physically held 5", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "robots collide at aisle intersections about once a week and the traffic manager logs look reasonable:\n\n11:02:14.101 [traffic] R-041 requests reservation for node N-A7-INT (aisle A7 intersection)\n11:02:14.104 [traffic] reservation granted to R-041, expires 11:02:44\n11:02:14.112 [traffic] R-018 requests reservation for node N-A7-INT\n11:02:14.115 [traffic] reservation denied, held by R-041\n11:02:14.118 [traffic] R-018 enters waiting state\n11:02:29.881 [traffic] R-041 heartbeat missed (last 11:02:14.104)\n11:02:29.884 [traffic] reservation for N-A7-INT released (holder unresponsive)\n11:02:29.887 [traffic] reservation granted to R-018\n11:02:31.114 [traffic] R-041 heartbeat resumed, continues along reserved path\n\nR-041 kept moving through the intersection during those fifteen seconds", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "elasticsearch rejects writes during our morning peak and the cluster looks healthy otherwise:\n\n{\n \"error\": {\n \"type\": \"es_rejected_execution_exception\",\n \"reason\": \"rejected execution of coordinating operation [coordinating_and_primary_bytes=0, replica_bytes=0, all_bytes=0, coordinating_operation_bytes=104857600, max_coordinating_and_primary_bytes=104857600]\"\n },\n \"status\": 429\n}\n\nnode stats:\n indexing.index_current: 412\n thread_pool.write.queue: 200 (capacity 200)\n thread_pool.write.rejected: 41,882\n jvm.mem.heap_used_percent: 71\n indices.indexing.index_time_in_millis rate: 88ms/doc\n\nwe bulk index in 50MB batches from four ingest workers", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "reservation logic in the traffic manager, which decides whether robots can enter a node:\n\npublic boolean tryReserve(String nodeId, String robotId, Duration ttl) {\n Reservation existing = reservations.get(nodeId);\n if (existing != null && !existing.isExpired(clock.instant())) {\n return false;\n }\n reservations.put(nodeId, new Reservation(robotId, clock.instant().plus(ttl)));\n return true;\n}\n\npublic void heartbeat(String robotId) {\n lastSeen.put(robotId, clock.instant());\n}\n\n// separate thread, every second\nreservations.entrySet().removeIf(e ->\n Duration.between(lastSeen.getOrDefault(e.getValue().robotId(), Instant.EPOCH), clock.instant()).getSeconds() > 15);\n\nis releasing a reservation on a missed heartbeat sound, given a robot that's still physically moving?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "design doc for our attempt model, written before the exam pilot. does it survive contact with 40,000 students?\n\n## Attempts\nAn attempt is created when a student opens a quiz and holds every answer as a row. Answers are upserted as the student progresses, so a lost connection loses nothing. An attempt is submitted once; submission is idempotent.\n\n## Assumptions\n- A student has one attempt open at a time.\n- Answers are small and can be written on every keystroke pause.\n- The client is authoritative for question order.\n\n## Not covered\nProctoring. Offline attempts. Two devices on the same attempt.\n\nstudents routinely open a quiz on a laptop and a phone, and \"upserted\" is a create in the code", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "kafka consumer config for the robot fleet, which rebalances constantly:\n\nmax.poll.records: 500\nmax.poll.interval.ms: 300000\nsession.timeout.ms: 10000\nheartbeat.interval.ms: 3000\nenable.auto.commit: true\nauto.commit.interval.ms: 5000\nfetch.min.bytes: 1\ngroup.instance.id: (unset)\n\ntwelve robots, each a consumer in the same group, each processing a task for up to 90 seconds; robots go offline briefly when they pass through the racking in aisle A7", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "npm audit before the exam period freeze, what goes in:\n\nnext 14.2.0 - 14.2.29\nSevere: Server-Side Request Forgery in Next.js image optimisation\nfix available via `npm audit fix --force`\nWill install [email protected], which is a breaking change\n\n@prisma/client 5.14.0 - 5.19.1\nModerate: Prisma Client leaks connection strings in error messages\nfix available via `npm audit fix`\n\nsharp 0.32.0 - 0.33.4\nHigh: Denial of service via crafted image\nfix available via `npm audit fix`\n\n4 vulnerabilities (1 moderate, 2 high, 1 severe)\n\nwe are three weeks from exam week and the next major is a two-day migration", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "enrichment providers each handle failure differently, which is why one slow provider stalls everything:\n\n# asn.py\nresp = requests.get(url) # no timeout at all\nreturn resp.json()[\"asn\"]\n\n# geo.py\ntry:\n resp = requests.get(url, timeout=2)\nexcept requests.Timeout:\n return None # silently unenriched\n\n# threatintel.py\nfor attempt in range(5):\n try: return requests.get(url, timeout=10).json()\n except Exception: time.sleep(attempt) # up to 10 seconds of sleeping in the pipeline\n\n# internal_assets.py\nreturn self.cache[ip] # KeyError propagates and kills the batch", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility requirement from a district's procurement, which we have to answer honestly:\n\n\"The platform shall conform to WCAG 2.2 AA. All assessment activities shall be completable using a keyboard alone and with a screen reader. Time limits shall be adjustable or extendable by an instructor for individual students. Content shall not rely on colour alone to convey meaning. The supplier shall provide a current VPAT and a remediation plan for any non-conformance.\"\n\nour quiz navigation is mouse-only in two places, time limits are per-assessment with no per-student override, and we have never produced a VPAT. i want the plan, the honest gaps, and what we can claim by the deadline in six weeks", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "bulk batches down to 5MB", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "alert list should support j and k", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "triage view needs a dark theme default", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "why does the group rebalance so often?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "aisle screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "teachers are dealing with duplicate attempts, an auto-submit job they don't know about and a review screen that shows only the latest attempt, and every one of those has generated support tickets this term. write the page that explains attempts as they actually work, in language a teacher will read the week before exams rather than during them the page should be readable in five minutes by someone who has never filed a support ticket.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "warehouse runbook still describes the conveyor system that was removed two years ago, and the robot procedures live in the shift supervisors' heads. write the runbook for the robot fleet, ordered by what someone woken at three in the morning needs first, and be explicit about which actions are never safe during operations the supervisors printing this will have it laminated, so keep it short and ordered.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "an auditor has asked six questions about telemetry collection, retention, tenant isolation, alert deletion, rule versioning and orphaned alerts, and at least three of our honest answers are unflattering. write the controls document from the code, marking what we can't substantiate rather than smoothing over it our compliance lead reads it first and would rather see a gap than a confident half-truth.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether a robot that loses wifi mid-aisle can have its reservation given away while it is still moving, or whether some other interlock saves us. read the traffic manager, the heartbeat handling and the sweep together, and tell me exactly what sequence of events produces the situation we saw in May", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "i'd like an honest read of whether our tenant isolation can be bypassed by a crafted rule, given that rules can specify their own index pattern, and the fix if it can", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "instructor dashboard times out for two institutions that are up for renewal, and i want the diagnosis before the rewrite. work out where the time actually goes, then restructure the query so it returns in under a second at their size both institutions are up for renewal, so a number i can quote would help.", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "rule versioning needs designing and starting in the same quarter. give me the model — immutable versions, alert references, what deletion means — then build the versions table and the write path so new alerts start carrying a version immediately", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "task API reference has to exist for the firmware team, and while writing it i'd like confirmation that late progress reports really are accepted and ignored, because the firmware treats that as success", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "three prisma query styles for a teacher's courses disagree about archived courses and one bypasses row-level security entirely. unify them, and tell me whether that raw query has been leaking other teachers' courses this whole time", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "is the grading recalculation safe to run concurrently for the same enrolment, or are we relying on luck", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "exam timer keeps counting while the browser tab is backgrounded on ios, which it shouldn't", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "we need a plan for running two warehouse sites from one WMS instance without them affecting each other", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "the aisle drain command should refuse while robots are inside and report which ones are blocking, rather than draining tasks and leaving the robots stranded mid-aisle as it does today. it also needs to be safe to call repeatedly from the console by a supervisor who is watching the screen rather than reading the response", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "our ingestion, enrichment and rules services each define their own dataclasses for the same event schema, which is why a field rename last month silently dropped enrichment for one event type. give them one shared schema definition with versioning, and confirm from a day of production events that nothing is parsed differently afterwards a field rename last month silently dropped enrichment for one event type and nobody noticed for a week.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "attempt design doc claims answers are upserted and submission is idempotent, and neither is true in the code as far as i can tell. go through the doc claim by claim against the current implementation and tell me which parts are aspirational, because exam week is close and i need to know what we actually have exam week is close enough that i need to know what we actually have rather than what we meant.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "one query style for detection rules", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "our three LMS components each implement optimistic updates with a different rollback strategy, and the quiz one rolls back to a value that may already be stale. unify them behind one approach, and while you're in there tell me whether the quiz rollback has ever silently discarded a saved answer", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "the course cache is a module-level Map with no eviction and it is most of our memory growth in production. put a bound and a TTL on it, then confirm from the request pattern whether caching there is worth keeping at all", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "quiz navigator and the drag-to-order questions both fail the accessibility audit and both need keyboard alternatives. fix them, and write the VPAT section covering assessment activities", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "detection rules are written in three different syntaxes because we added a friendlier one without removing the others, and only the newest validates field names. before consolidating i want a view on whether we can migrate existing rules automatically, what we'd break for analysts who write raw DSL, and whether the friendlier syntax is expressive enough for the rules that matter", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "robot firmware team integrates against our task API from a wiki page written in 2023, and the two things they consistently get wrong are lease expiry and the fact that late progress reports are accepted but ignored. write the reference documentation with those two impossible to misread, including what a robot should do when it gets a 409 the firmware release cycle is six weeks, so anything ambiguous costs us a quarter.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does our nightly sync make when the district's API returns a partial page", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "a walkthrough of how a pick becomes an inventory movement would help before i touch reconciliation", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "one aisle stops receiving tasks", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "attempt lifecycle is five nullable timestamp columns and eleven ad-hoc checks, three of which forget the voided case entirely. model it as an explicit state machine, migrate the existing rows including the merged ones, and keep every current query returning the same rows it does today the merged attempts from the support scripts are the awkward rows, and there are about two hundred.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "pick tasks stop flowing to one aisle every few days, kafka side looks fine to me:\n\n2026-07-29T11:02:14Z INFO [task-dispatcher] assigning task 88412 to robot R-041 aisle=A7\n2026-07-29T11:02:14Z INFO [task-dispatcher] produced to topic wms.tasks partition=3 offset=41882104\n2026-07-29T11:02:44Z WARN [task-dispatcher] no ack from R-041 after 30s, task 88412 requeued\n2026-07-29T11:03:14Z WARN [task-dispatcher] no ack from R-041 after 30s, task 88412 requeued\n2026-07-29T11:03:44Z ERROR [task-dispatcher] task 88412 exceeded requeue limit, dead-lettered\n2026-07-29T11:03:45Z INFO [consumer-group wms-robots] rebalance triggered, 12 members\n2026-07-29T11:03:52Z INFO [consumer-group wms-robots] rebalance complete, R-041 assigned partitions [3]\n\nrebalances happen every few minutes and R-041's logs show it never received the task at all", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "course player buffers on video for one school district and nobody else:\n\nnetwork tab, same lesson, two sites:\n district A: GET /media/lesson-4471/hls/720p/seg_00041.ts 200 1.2MB ttfb 2,841ms total 8,112ms\n district B: GET /media/lesson-4471/hls/720p/seg_00041.ts 200 1.2MB ttfb 88ms total 214ms\n\nresponse headers (district A):\n x-cache: MISS\n age: 0\n cf-ray: 8f2b1c40-ORD\n vary: Origin, Accept-Encoding, Cookie\n\ndistrict A's proxy adds a `Cookie` header to every media request, district B's doesn't", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "SIEM's enrichment lookups time out under load and the queue backs up:\n\npy-spy dump --pid 41221:\nThread 0x7f1a (active): \"MainThread\"\n _wait_for_tstate_lock (threading.py:1116)\n join (threading.py:1096)\n enrich_batch (enrichment/pipeline.py:141)\n process (enrichment/pipeline.py:88)\nThread 0x7f2b (idle): \"enrich-0\"\n read (socket.py:718)\n _read_status (http/client.py:280)\n getresponse (http/client.py:1428)\n lookup_asn (enrichment/providers/asn.py:41)\n\n... 63 more idle threads, all in lookup_asn\n\nthe ASN provider has no timeout set on its session, and we spawn one thread per event in a batch of 500", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "las notas calculadas no coinciden con las que ven los profesores, aquí un caso:\n\nalumno 4471, curso \"Álgebra II\"\n tarea 1 nota 8,5 peso 20%\n tarea 2 nota 7,0 peso 20%\n examen nota 6,5 peso 60%\n\ncálculo esperado: 8,5*0,2 + 7,0*0,2 + 6,5*0,6 = 7,00\ncálculo mostrado en el panel del profesor: 7,00\ncálculo mostrado al alumno: 7,33\ncálculo en el export CSV: 7,0\n\nel panel del alumno redondea antes de ponderar, y el export usa una consulta distinta escrita hace dos años", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "es"}
{"prompt": "next.js app leaks memory in production and the pod restarts every few hours:\n\nheap snapshot comparison (30 min apart):\n (array) +412 MB +1,204,118 objects\n Prisma.QueryEngine +188 MB\n (closure) +141 MB +882,441 objects\n Response +88 MB\n Map +41 MB\n\nretainers for the largest (array):\n global → cacheMap → Map → entries → Array\n app/lib/courseCache.ts:22\n\ncourseCache is a module-level Map keyed by course id, populated on every request, never evicted, and the server runs in a long-lived node process", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "grading service's concurrency, which i'd like a second opinion on before we scale it up:\n\n@Transactional\npublic Grade recalculate(Long enrolmentId) {\n Enrolment e = enrolments.findById(enrolmentId).orElseThrow();\n List<Submission> subs = submissions.findByEnrolment(e.getId());\n BigDecimal total = BigDecimal.ZERO;\n for (Assessment a : e.getCourse().getAssessments()) {\n Submission s = subs.stream().filter(x -> x.getAssessmentId().equals(a.getId()))\n .max(comparing(Submission::getAttempt)).orElse(null);\n if (s == null) continue;\n total = total.add(s.getScore().multiply(a.getWeight()));\n }\n e.setGrade(total.setScale(2, RoundingMode.HALF_UP));\n return grades.save(new Grade(e, total));\n}\n\nthis runs on submission, on assessment weight changes, and nightly for every enrolment in the institution", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "bitte einmal drüberschauen, bevor das in die Prüfungsphase geht:\n\nexport async function POST(req: Request, { params }: { params: { id: string } }) {\n const body = await req.json()\n const attempt = await prisma.attempt.findUnique({ where: { id: params.id } })\n if (!attempt) return new Response(\"not found\", { status: 404 })\n if (attempt.submittedAt) return new Response(\"already submitted\", { status: 409 })\n await prisma.answer.create({\n data: { attemptId: attempt.id, questionId: body.questionId, value: body.value },\n })\n return Response.json({ ok: true })\n}\n\nder Client sendet bei langsamer Verbindung erneut, und es gibt keinen Idempotenzschlüssel; in der Prüfungswoche sind das 40.000 gleichzeitige Versuche", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "ingestion pipeline's batching, which i suspect is why elasticsearch rejects us:\n\ndef run(self):\n batch = []\n for event in self.source:\n batch.append(self.transform(event))\n if len(batch) >= self.batch_size: # batch_size = 10_000\n self.es.bulk(body=batch, request_timeout=120)\n batch = []\n if batch:\n self.es.bulk(body=batch, request_timeout=120)\n\nfour workers run this, batch_size is 10,000 documents which averages 50MB, there's no retry on 429, and a rejected bulk loses the whole batch silently because we don't check the per-item response", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "query behind the instructor dashboard, which times out for our largest institution:\n\nSELECT c.id, c.title, count(distinct e.student_id) AS students,\n avg(g.value) FILTER (WHERE g.value IS NOT NULL) AS avg_grade,\n count(*) FILTER (WHERE s.submitted_at IS NULL AND a.due_at < now()) AS overdue,\n (SELECT count(*) FROM messages m WHERE m.course_id = c.id AND m.read_at IS NULL) AS unread\nFROM courses c\nJOIN enrolments e ON e.course_id = c.id\nLEFT JOIN grades g ON g.enrolment_id = e.id\nLEFT JOIN assessments a ON a.course_id = c.id\nLEFT JOIN submissions s ON s.assessment_id = a.id AND s.student_id = e.student_id\nWHERE c.institution_id = $1 AND c.archived_at IS NULL\nGROUP BY c.id, c.title;\n\n1,200 courses, 88,000 enrolments, 4.1M submissions for that institution", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the exam-week incidents, they need to become a page teachers can read:\n\n- students on flaky wifi sometimes see \"answer not saved\" and refresh, which creates a second attempt\n- teachers then see two attempts and don't know which is authoritative — it's the one with the later submittedAt\n- an attempt with no submittedAt after the exam window closes is auto-submitted by a nightly job, which teachers don't know exists\n- the review screen shows answers from the latest attempt only, which is why students say answers \"disappeared\"\n- teachers can merge attempts through a support ticket, which takes a day and a database script\n- none of this is in any documentation, and exam week is in three weeks\n\nwrite the page for teachers, and separately tell me which of these are documentation problems and which are product problems", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "notes from the security team's rule review, i need to turn them into a rule-writing guide for analysts:\n\n- every rule needs an owner, a rationale and an expected volume, and today most have none\n- rules imported from blog posts are the biggest source of noise; the SMB one fires 40 times a day\n- suppression by source.ip for known management hosts should be the default, not an afterthought\n- thresholds are absolute counts, so a rule tuned for one customer's volume is wrong for another\n- rules query `logs-*` by habit, which now includes tomorrow's index and non-EDR data\n- there's no test procedure; analysts write a rule and see if it fires in production\n- a rule that generates zero alerts for a week should be reviewed, not left running\n\nwrite the guide, aimed at analysts who write rules but don't operate the platform", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "o resumo do incidente de ontem, para as escolas afetadas:\n\n09:12 professores relatam que as notas mostradas aos alunos não coincidem com o painel\n09:40 confirmamos: o painel do aluno arredonda antes de ponderar\n10:05 verificamos que o export CSV usa uma consulta diferente, escrita há dois anos\n10:30 três cálculos distintos identificados para a mesma nota\n11:15 decidimos que o painel do professor é a fonte de verdade\n12:00 correção aplicada aos outros dois; nenhuma nota gravada estava errada\n\nnenhum aluno foi avaliado incorretamente, mas alguns viram um valor diferente durante cerca de três horas; as escolas querem saber se as notas finais foram afetadas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "pt"}
{"prompt": "WMS operator's manual covers the old conveyor system and nothing about the robots. what's true now:\n\n- tasks are dispatched from the WMS to a robot fleet over kafka, with a 90 second lease\n- a robot that loses connectivity keeps executing its current task and reports on reconnect\n- the traffic manager grants node reservations; a robot without a reservation stops and waits\n- an aisle can be put into maintenance mode from the console, which drains tasks but does not recall robots already inside\n- cycle counts run nightly and discrepancies over 2 units page the shift supervisor\n- there is a physical e-stop per aisle that the software cannot override, and a software pause that it can\n- recovering a stuck robot means driving it manually from the console, which requires a role most supervisors don't have\n\nwrite the operator's manual section for the robot fleet", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the LMS release, from the commits since 6.3:\n\n41c9e0b fix(attempts): answers are upserted rather than created, fixing lost answers on retry\n88f21c0 feat(grading): one grading path for the student view, teacher view and export\nc0aa774 fix(media): media requests no longer vary on Cookie, restoring CDN caching\n2e91b45 feat(exams): attempts can be merged from the teacher's screen\naa30f19 perf(dashboard): instructor dashboard query rewritten, 8s to 400ms\n9c1d004 chore: minimum node version is now 22\n4410bb7 fix(a11y): quiz navigation is keyboard operable\nb77e910 feat(api): institution-scoped API tokens\n\nour readers are school IT administrators; two of these change behaviour they'll notice and one needs action from them", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "auditor's questions about our SIEM deployment, which we've never had to answer in writing:\n\n1. What data is collected from endpoints, and can a customer see the full list?\n2. How long is raw telemetry retained, and where?\n3. Who can read another tenant's alerts, and how is that prevented?\n4. Can an analyst delete an alert, and is that recorded?\n5. How are detection rules versioned, and can you show which rule version produced a given alert?\n6. What happens to alerts when a rule is deleted?\n\nour rules live in a git repo but alerts store only the rule name; deleting a rule leaves orphaned alerts; and tenant isolation is a filter applied in the query layer\n\nwrite the controls document, marking clearly what we cannot currently substantiate", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "我们的告警规则文档只有一个示例，运维和分析师都在猜。目前规则引擎的实际行为如下：\n\n- 规则每 5 分钟执行一次，查询窗口默认也是 5 分钟，两者不一致时以窗口为准\n- 窗口是左闭右开，边界上的事件会在两个窗口中被计算一次还是零次，取决于 `@timestamp` 的精度\n- 阈值是绝对值，不随数据量缩放；同一条规则在不同租户下的表现完全不同\n- 抑制（suppression）只按字段去重,不做时间衰减，抑制窗口固定 1 小时且不可配置\n- 规则被删除后，已产生的告警仍然保留，但无法回溯到规则内容\n- 规则里写 `index: logs-*` 会匹配到未来日期的索引，这在跨时区部署里会导致漏报\n\n请写成给分析师看的规则编写文档，把窗口边界和抑制这两点讲清楚\n\n目前规则文件长这样，文档里也只有这一个例子：\n\nname: Suspicious SMB session enumeration\nindex: logs-edr-*\ninterval: 5m\nwindow: 5m\nquery: |\n event.code:5145 and winlog.event_data.ShareName:\"\\\\\\\\*\\\\IPC$\"\nthreshold:\n field: source.ip\n value: 10\nsuppression:\n by: [source.ip]\n window: 1h # 实际上这个字段被忽略，永远是 1 小时\nseverity: high\nowner: (empty)\n\n另外，规则删除后 alerts 表里的 rule_name 还在，但 rule body 无法追溯", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "zh"}
{"prompt": "on-call runbook for the warehouse is a laminated sheet from the conveyor era. what the team does now:\n\n- \"aisle stopped\" is the most common page; first check whether it's an e-stop (physical) or a software pause\n- if the traffic manager is granting reservations but robots aren't moving, restart the dispatcher, not the traffic manager\n- restarting the traffic manager during operations releases every reservation at once, which is how we had the near-miss in May\n- a robot that missed its heartbeat but is still moving is the dangerous case; the only safe action is the aisle e-stop\n- kafka consumer lag above 500 on wms.tasks means the dispatcher is behind and picks will be late, not lost\n- never drain an aisle that has robots inside it; drain, then wait for the aisle to report empty\n\nwrite the runbook, ordered by what a supervisor at 3am would need first", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "eslint and tsc on the LMS app, the gate goes on next sprint:\n\napp/lib/courseCache.ts:22:14 - error TS7034: Variable 'cacheMap' implicitly has type 'any' in some locations\napp/api/attempts/[id]/answers/route.ts:41:22 - error TS2345: Argument of type 'string | null' is not assignable to parameter of type 'string'\napp/components/QuizNav.tsx:88:5 - warning: Static HTML elements with event handlers require a role (jsx-a11y/no-static-element-interactions)\napp/components/QuizNav.tsx:112:9 - warning: Visible, non-interactive elements with click handlers must have at least one keyboard listener\napp/lib/grades.ts:141:3 - error TS2554: Expected 2 arguments, but got 3\n\n3 errors, 2 warnings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "spotbugs on the WMS service, two of these look real:\n\nM C RCN: Nullcheck of value previously dereferenced in TrafficManager.tryReserve(String, String, Duration)\nM P UPM: Private method TaskDispatcher.requeue(Task) is never called\nH C IS2: Inconsistent synchronization of TrafficManager.reservations; locked 60% of time\nM D DM: TaskDispatcher.assign() invokes inefficient new String() constructor\nH C EC: Call to equals() comparing Robot and String in FleetRegistry.find(String)\n\n5 warnings, and IS2 on the reservations map is the one i keep thinking about", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "index lifecycle policy versus what we actually keep, one of these is wrong:\n\nPUT _ilm/policy/edr-logs\n{\n \"policy\": {\n \"phases\": {\n \"hot\": { \"actions\": { \"rollover\": { \"max_primary_shard_size\": \"50gb\", \"max_age\": \"1d\" } } },\n \"warm\": { \"min_age\": \"7d\", \"actions\": { \"shrink\": { \"number_of_shards\": 1 } } },\n \"cold\": { \"min_age\": \"30d\", \"actions\": { \"searchable_snapshot\": { \"snapshot_repository\": \"s3\" } } },\n \"delete\": { \"min_age\": \"90d\", \"actions\": { \"delete\": {} } }\n }\n }\n}\n\nour contract with two customers says 12 months of searchable telemetry, and our marketing page says 13 months", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "CDN config for lesson media, which is why one district gets no caching at all:\n\ncache_rules:\n - path: \"/media/*\"\n cache: { ttl: 604800, key: [path, query, header:Cookie, header:Origin] }\n - path: \"/api/*\"\n cache: { ttl: 0 }\n\norigin response headers:\n cache-control: public, max-age=604800\n vary: Origin, Accept-Encoding, Cookie\n\nthe media is identical for every student and requires a signed URL in the query string, which is already in the cache key", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "kafka consumer settings, prod versus the values the vendor recommends:\n\n# ours\nsession.timeout.ms: 10000\nheartbeat.interval.ms: 3000\nmax.poll.interval.ms: 300000\ngroup.instance.id: unset\npartition.assignment.strategy: RangeAssignor\n\n# vendor's recommendation for mobile consumers\nsession.timeout.ms: 45000\nheartbeat.interval.ms: 15000\nmax.poll.interval.ms: 300000\ngroup.instance.id: <stable per robot>\npartition.assignment.strategy: CooperativeStickyAssignor\n\nour robots drop off wifi for 5-20 seconds when they pass through racking, and every drop triggers a full group rebalance", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "les seuils d'alerte du WMS, on est réveillés pour rien mais on rate les vrais problèmes :\n\n- alert: ConsumerLag\n expr: kafka_consumergroup_lag{group=\"wms-robots\"} > 100\n for: 1m\n labels: { severity: page }\n\n- alert: RobotOffline\n expr: up{job=\"robot\"} == 0\n for: 0m\n labels: { severity: page }\n\n- alert: TaskDeadLettered\n expr: increase(wms_tasks_dead_lettered_total[1h]) > 0\n for: 0m\n labels: { severity: ticket }\n\nles robots passent hors ligne 5 à 20 secondes en traversant les rayonnages, le lag dépasse 100 à chaque vague de commandes, et le vrai incident de mai (une réservation libérée sous un robot en mouvement) n'a déclenché aucune alerte", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "fr"}
{"prompt": "this dispatcher has grown five responsibilities and a scheduled executor. same behaviour, separable pieces:\n\npublic class TaskDispatcher {\n // builds the pick list from open orders\n // chooses a robot by capability, distance and current load\n // produces to kafka and tracks the lease\n // requeues on missed ack, dead-letters after three attempts\n // emits metrics and writes an audit row per assignment\n // runs a scheduled sweep every second for expired leases\n}\n\n800 lines, one test that boots the whole spring context and a real kafka container, and the lease sweep is the part we most need to change", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "drei Stellen bauen dieselbe Prisma-Abfrage für „Kurse eines Lehrers\", leicht unterschiedlich:\n\n// app/api/courses/route.ts\nprisma.course.findMany({ where: { teacherId, archivedAt: null }, include: { assessments: true } })\n\n// app/dashboard/page.tsx\nprisma.course.findMany({ where: { teacherId }, include: { assessments: true, enrolments: true } })\n\n// lib/reports.ts\nprisma.$queryRaw`SELECT * FROM courses WHERE teacher_id = ${teacherId} AND archived_at IS NULL`\n\ndie zweite vergisst archivierte Kurse auszuschließen, die dritte umgeht das Row-Level-Security-Setup komplett", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "de"}
{"prompt": "planning input for the term, and i need it sequenced against exam week:\n\n- exam week is in three weeks and lost answers are our most damaging bug\n- the instructor dashboard times out for our two largest institutions, both of whom are up for renewal\n- the WMS traffic manager has a safety-adjacent bug that legal wants addressed before the next site goes live\n- the SIEM's detection rules are noisy enough that the customer's SOC has started ignoring them\n- two engineers are shared across the LMS and the WMS, and neither product is moving\n- a customer wants 12 months of searchable telemetry, we currently delete at 90 days\n- there's a node major version upgrade we've deferred twice", "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\nWMS-702 — Safety-critical reservation handling\nThe traffic manager releases a node reservation when a robot's heartbeat is missed for 15 seconds, on the assumption that a silent robot has stopped. In May a robot passed through racking, lost wifi, kept moving, and its reservation was granted to another robot. Nobody was hurt and no goods were damaged. The proposal is to require positive confirmation of a stop before releasing, which means a robot that genuinely dies blocks its node until a human intervenes. Constraints: robots have no independent radio; the aisle e-stop is the only guaranteed stop; and throughput targets assume reservations are released within seconds.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.95, "slice": "pasted-context", "lang": "en"}
{"prompt": "SIEM team's wishlist, one engineer, one quarter:\n\n- rule versioning, so an alert can be traced to the rule text that produced it\n- a test harness for rules against recorded telemetry, instead of writing to production\n- per-tenant thresholds, because absolute counts don't work across customers of different sizes\n- suppression that decays rather than a fixed one-hour window\n- retention to 12 months for two contracts, which is a storage and cost question as much as a technical one\n- the ingestion pipeline stops losing whole batches when elasticsearch rejects them\n\nwhat's the order, and which of these is secretly the biggest", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the quiz player, which has to work under exam conditions:\n\nQuiz player\n- One question per screen on mobile, optional all-questions view on desktop; the choice persists per student.\n- Question navigator: a grid of numbers, showing answered / unanswered / flagged, always reachable by keyboard.\n- Autosave indicator: a small text state — \"Saved 11:02\", \"Saving…\", \"Not saved — retrying\" — never a spinner that lies.\n- Offline: answers queue locally and the banner says exactly what is unsaved; the submit button is disabled while anything is queued.\n- Timer: fixed at the top, warns at five minutes and one minute, announced politely rather than continuously.\n- Submission: a confirmation listing unanswered questions, which is the only blocking dialog in the flow.\n- Everything keyboard operable, focus visible, and no interaction that requires a hover.\n- Must degrade to a plain form if JavaScript fails mid-exam, because it has happened.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the warehouse console's aisle view, which supervisors watch all shift:\n\nAisle view\n- Top-down schematic of one aisle, racking either side, robots as arrows showing heading, updating at 4Hz over websocket.\n- Node reservations drawn as translucent overlays with the holding robot's id; expiring reservations pulse in the last three seconds.\n- Robot cards along the right: id, battery, current task, lease remaining, last heartbeat age. Cards sort by problem state first.\n- A robot with a missed heartbeat is unmistakable — not just a colour, but a striped overlay and a persistent banner.\n- Controls: software pause per aisle, drain, and per-robot manual drive, all behind a role check with the button absent rather than disabled.\n- The e-stop state is displayed but never controllable from software.\n- Everything must be legible from two metres on a wall-mounted screen, and must not depend on hover for any information.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility audit of the LMS, which a district commissioned before renewal:\n\n1. Quiz question navigation is mouse-only; the number grid cannot be reached or operated by keyboard.\n2. The autosave state is conveyed by a coloured dot with no text alternative.\n3. The exam timer is announced by screen readers on every tick, making the page unusable.\n4. Drag-to-order questions have no keyboard alternative at all.\n5. Focus is lost to the document body after every question transition.\n6. Error messages on the submission dialog are not associated with the controls they refer to.\n7. Contrast on the \"flagged\" question state is 2.7:1 against the grid background.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "analyst console's alert triage screen, spec from the SOC team who use it eight hours a day:\n\nTriage view\n- Alert list on the left, virtualised, grouped by rule with counts; keyboard j/k moves, enter opens, e escalates, s suppresses.\n- Detail pane: the matched events in a table, the rule text as it was at match time, and the enrichment results with their source and age.\n- Enrichment that failed must say so explicitly rather than showing an empty field.\n- Timeline of related alerts for the same entity within 24 hours, on one axis, clickable.\n- Bulk actions on a selection, with an undo window of ten seconds rather than a confirmation dialog.\n- Every action records who, when and why; the why is a required free-text field for escalation and suppression.\n- Dark theme is the default because the SOC runs with the lights down, and both themes must pass contrast.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "integration spec a district's student information system expects from us:\n\nOneRoster 1.2 REST, we implement the consumer side\n GET /ims/oneroster/rostering/v1p2/orgs/{id}/classes paginated, up to 20k classes\n GET .../classes/{id}/students and .../classes/{id}/teachers\n sync nightly; the district publishes changes at 02:00 local time and expects us current by 07:00\n enrolment removals are soft — a student disappearing from a class must not delete their submissions\n the district's ids are opaque strings and are not stable across academic years\n they rate limit us to 10 requests per second and will not raise it\n a partial sync must be resumable, and a failed sync must not leave students without access at 08:00", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for rule versioning, now it needs building:\n\nCREATE TABLE rule_versions (\n id uuid PRIMARY KEY,\n rule_id uuid NOT NULL,\n version int NOT NULL,\n body jsonb NOT NULL,\n author text NOT NULL,\n created_at timestamptz NOT NULL DEFAULT now(),\n active_from timestamptz,\n active_to timestamptz,\n UNIQUE (rule_id, version)\n);\n\nalerts must reference the rule_version that produced them; deleting a rule must not orphan alerts; an analyst editing a rule creates a new version rather than mutating; and the triage screen has to show the rule text as it was when the alert fired, which means versions are immutable once any alert references them", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "retention to 12 months on the EDR policy", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "sharp bump before the freeze", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "drop Cookie from the media cache key", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "the console lets a supervisor drive a robot manually and i genuinely don't know what happens if they do that while the robot holds a node reservation and has an active task lease. work through the interaction between manual drive, the traffic manager and the dispatcher, and tell me which of the three thinks it is in charge", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our python services load configuration three different ways and the SIEM one reads environment variables at import time, which is why a config change needs a restart nobody expects. unify the loading, then document the new precedence so operators stop guessing", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "certificate email says \"Congradulations\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "session timeout to 45s for the robots", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "el botón de entrega sigue en inglés", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "es"}
{"prompt": "stable group.instance.id per robot", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "rules should query logs-edr-* not logs-*", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "add a timeout to the ASN lookup", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "Kurs-Cache begrenzen, er wächst unbegrenzt", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
{"prompt": "RobotOffline needs a 30 second delay", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "question navigator grid, keyboard operable", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "autosave state needs text, not a dot", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "reservation overlays on the aisle view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "failed enrichment shows an empty field", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "試験タイマーが毎秒読み上げられます", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
{"prompt": "flagged state fails contrast", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "focus is lost between questions", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "pull the lease sweep out of the dispatcher", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "une seule requête pour « cours du professeur »", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "fr"}
{"prompt": "`enrolment` spelling, pick one", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "extract the rule query builder", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "inline the single-use `scoreFor`", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "docstrings for the task lease API", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "release notes for LMS 6.4", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota para as escolas sobre as notas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "pt"}
{"prompt": "document the auto-submit job for teachers", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the reservation proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the grading unification", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "can a reservation outlive a moving robot?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "¿por qué las reglas dejaron de disparar?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "walk me through the nightly auto-submit", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "answers disappear from the review screen", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "elasticsearch rejects our morning writes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "warum wächst der Heap bis zum Neustart?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a rule's version history", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "onwards with that", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "calmer alerts", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "whatever helps before exams", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "neaten it up", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "like last week", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "audit answers", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "encore le tableau de bord", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "fr"}
{"prompt": "something quick", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "give it another read", "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": "usual for this sprint", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "traffic manager releases a node reservation when a robot's heartbeat has been missing for fifteen seconds, on the assumption that a silent robot has stopped, and in May that assumption was wrong in the most alarming possible way. i want the options for making this safe worked through properly — positive stop confirmation, independent sensing, aisle-level interlocks — with an honest view of what each does to throughput and what happens when a robot genuinely dies mid-aisle legal has asked for this in writing before the next site goes live, so the reasoning matters as much as the answer.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.95, "slice": "core", "lang": "en"}
{"prompt": "SOC has started ignoring our alerts, which makes the whole product pointless regardless of how good the detection is. work through what would actually restore trust — rule versioning, testing against recorded telemetry, per-tenant thresholds, decaying suppression — and tell me which of those is secretly the biggest piece of work rather than the most obviously useful their own metric is alerts investigated per shift, which has halved since january.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "two of our contracts promise twelve months of searchable telemetry and our lifecycle policy deletes at ninety days, which somebody is going to notice during an investigation rather than during a review. work out what twelve months actually costs across hot, warm and cold tiers at our current volume, and what the honest options are including renegotiating", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "analysts write detection rules by copying blog posts and seeing what fires in production, which is how we ended up with forty false positives a day from one rule. write the rule-authoring guide — ownership, rationale, expected volume, suppression, thresholds, testing — aimed at analysts who write rules but never operate the platform the SMB rule is the example everyone recognises, so it's worth walking through it.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "detection rules stopped generating alerts overnight and the only unusual event was tomorrow's index being created at seven minutes past two. work through how the rules resolve indices and time windows, and tell me whether that index explains it or whether it's a coincidence i've latched onto the deployment spans three timezones, if that turns out to matter.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "enrichment providers each invent their own failure handling — one has no timeout, one silently returns nothing, one sleeps ten seconds inside the pipeline, one throws and kills the batch. give them one interface with explicit timeouts and failure semantics, keeping each provider's successful output exactly as it is today the ASN provider is the one currently taking the pipeline down, so start the analysis there.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "inventory drifts by a few units a day and the two picks in the sample were dispatched from the same snapshot of five units, which smells like the dispatcher reading availability without reserving it. work through the ordering of the task, the pick and the inventory event before we propose anything reconciliation runs at eighteen hundred and the discrepancies are always small and always negative.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "aisle view is what supervisors watch all shift and it currently conveys a missed heartbeat with a colour change nobody notices from two metres. build the view to the new spec, with the problem states unmistakable and the e-stop state visible but never controllable from software the screens are wall-mounted at about two metres and nobody is going to hover over anything.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "before we touch the traffic manager i want the safety argument written down — what we assume, what guarantees each layer provides, where a single failure is tolerated — and then the heartbeat handling changed to whatever that argument says is defensible the May near-miss is the case the argument has to explain, not just the happy path.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.95, "slice": "mixed", "lang": "en"}
{"prompt": "attempt model needs to handle two devices and flaky connections properly, which is a design question, and it needs to stop losing answers before exams, which is urgent. do the design first, then the idempotent answer write against it students routinely start on a laptop and finish on a phone, which nobody designed for.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "die Anreicherungspipeline blockiert regelmäßig komplett, wenn ein Anbieter langsam ist. Ich hätte gern zuerst ein Konzept für Timeouts, Nebenläufigkeit und Rückstau und danach die Umsetzung für den ASN-Anbieter, weil der uns gerade am häufigsten umbringt", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "de"}
{"prompt": "teachers need the attempts page written for them before exam week, and writing it will make obvious which parts are product bugs rather than missing documentation. produce the page, and give me the separate list of things we should fix instead of explaining last term generated forty support tickets, most of them the same three questions.", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la documentación del motor de reglas para los analistas y comprueba en el código si la ventana de supresión es realmente fija en una hora, porque el equipo cree que es configurable", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "es"}
{"prompt": "warehouse runbook needs writing and the aisle-drain procedure needs fixing, because draining an aisle with robots inside is currently possible from the console. write the runbook, then put the guard in", "purpose": "writing", "secondary": "backendImpl", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "task dispatcher does five things and the lease sweep is the one we need to change for safety reasons. separate them, then document the new boundaries so the next change doesn't have to understand all five", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "rule engine's three query syntaxes should become one. migrate the existing rules, and write the note explaining to analysts what changed and which of their rules were rewritten", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "one district gets no CDN caching on lesson media and the Vary header is the obvious suspect, but their proxy adds a Cookie to every request so it may be their side. confirm which it is, then fix whichever end we control every other district on the same build is fine, which is what makes me suspect their proxy.", "purpose": "debugging", "secondary": "quickFix", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "robots rebalance constantly and one aisle periodically stops receiving tasks, which i think are the same problem. diagnose it properly, then change the consumer configuration to whatever the diagnosis says rather than what the vendor's blog recommends", "purpose": "debugging", "secondary": "quickFix", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "triage screen needs bulk actions with an undo window, and the SOC wants to know what \"undo\" means for an escalation that already paged someone. design that interaction with me, then build it", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "npm audit has one severe finding whose fix is a major version we can't take three weeks before exams. work out the exposure honestly, apply what's safe, and tell me what compensating control covers the rest", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "per-tenant thresholds need to exist before the next customer onboards, and the shape matters — absolute, relative to baseline, or both. decide with me, then implement", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "rename `Task` in the WMS service, it collides with the scheduler's Task and the API's TaskDto", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain what happens to an attempt when a student opens the same quiz on a second device", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "why does our SMB rule fire forty times a day from the same six servers", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "someone should check whether an analyst can delete an alert without leaving a trace", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that a robot keeps executing a task it can no longer report progress on", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "docs/attempts.md says answers are upserted, which stopped being true in the rewrite", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "a short note explaining why the lease sweep is moving out of the dispatcher, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "API changelog needs an entry for institution-scoped tokens and what they replace", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "javadoc on tryReserve promises exclusivity that the sweep thread quietly breaks", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer note about telemetry retention changing from 90 days to 12 months", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "precisamos de uma página que explique aos professores como funcionam as tentativas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "pt"}
{"prompt": "health endpoint reports the rules engine healthy while it has produced zero alerts for six hours", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "dead-letter alert only fires on an increase over an hour, so a steady trickle is invisible", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "how should we handle student ids that change between academic years without losing submission history", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test the traffic manager, given that the failure mode is two robots in one place", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether detection rules belong in git or in the database now that they need versions", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "three districts want single sign-on with three different identity providers, what should our approach be", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to alerts when a customer offboards, given the contract says we delete their data", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns an attempt's full answer history including superseded values, for teachers", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "bulk indexer should check per-item responses and retry only the rejected documents", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "alert timeline should show related alerts for the same entity within 24 hours on one axis", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "instructor dashboard needs a loading skeleton that doesn't shift the layout when data arrives", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "robot cards should show lease remaining as a countdown rather than an absolute timestamp", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "quiz submission dialog should list unanswered questions as links, not just a count", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "anything that survives exam week", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "back to the rules engine", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "i'd like to understand what happens to a task lease when kafka rebalances mid-execution, because a robot that keeps working while its partition moves is exactly the shape of the aisle-stall bug. trace the interaction properly and tell me whether the lease and the partition assignment can ever disagree about who owns a task", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "submissions need a client-supplied idempotency key so that a retry on a slow connection cannot create a second answer row, which is the mechanism behind the answers students say disappear. design the key's scope and lifetime, implement the write path, and make sure an old client without the header still works during exam week", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "exam week needs the health endpoint to stop lying about the rules engine, and it needs an alert when zero alerts have been produced for an hour. do both, and tell me what else in our monitoring reports healthy while producing nothing", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "nobody has been able to tell me what the grading worker does when an assessment's weight changes after grades have been published — whether it recalculates silently, waits for the nightly run, or leaves the published grade alone. read the recalculation path and the nightly job together and tell me what a student would actually see in each case", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "our LMS notification code sends email, in-app and push from three different places with three different templating approaches, and a student who has muted a course still gets the push. bring them behind one notification service with preferences applied in one place, keeping every existing message identical in wording and timing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "the SIEM's alert model carries both the matched documents and a denormalised copy of the entity fields, which have drifted apart since the enrichment rewrite. settle on one representation, migrate the existing alerts, and keep the triage screen showing exactly what it shows today for alerts that predate the change", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "we need an endpoint that returns a student's full submission history for a course, including superseded answers and the attempt each came from, because teachers currently ask support for a database export. it has to be paginated, cheap enough to call from the teacher's screen, and must not expose other students' data through a guessable id", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt":"Split projects/isotope/ml/pipeline/features.py by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-49139: finish the compact IsotopeHarborIndexFlow filter experience\n\nRoute: /catalog/search\nSource: projects/isotope/ui/settings/PrivacyPane.tsx\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\nFinish the visible IsotopeHarborIndexFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"IsotopeSummitProxyCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Center the IsotopeAmberFilterService modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"Walk through IsotopeIrisBatchStore's SyncWorker.kt","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/isotope/Sources/App/SessionStore.swift b/projects/isotope/Sources/App/SessionStore.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/Sources/App/SessionStore.swift\n+++ b/projects/isotope/Sources/App/SessionStore.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\nRestructure IsotopeCloudReconcilerFlow 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":"Wire a IsotopeFlintTimelineFlow background task in projects/isotope/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.6,"slice":"core","lang":"en"}
{"prompt":"Production says IsotopeFlintTimelineService is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. 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- touch generated artifacts only through their checked-in generator\n- keep the patch readable for a small on-call review\n- retain the current PostgreSQL 17 operational envelope\n\nThis repository spans media encoding, Python ML, Windows; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Cinder: The IsotopeLedgerGateService 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":"IsotopeSableParserCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Teach IsotopeOpalRouterStore to verify signed continuation tokens, reject cross-tenant cursors, and rotate keys without invalidating tokens issued during the overlap window.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"// projects/isotope/crates/index/src/segment.rs\nfinal class IsotopeBeaconStoreFlowCoordinator {\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 IsotopeBeaconStoreFlow; 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":"Could IsotopeNovaPickerService show the active NATS JetStream 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":"IsotopeKiteSchedulerCoordinator: correct, then assess","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Delta: projects/isotope/packages/api/openapi.yaml の IsotopeGarnetModalFlow で、NATS JetStream の flow に断続的な問題が起きています。 責務を分離して重複をなくし、API、wire value、順序、観測可能な動作は変えないでください。\n\n制約:\n- NATS JetStream を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は IsotopeGarnetModalFlow のみ","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"ja"}
{"prompt":"Ember: Incident timeline — INC-49124\n\n08:02 deploy IsotopeAmberFilterFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nDetermine why IsotopeAmberFilterFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":"planning","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/isotope/Sources/CLI/Commands/Doctor.swift b/projects/isotope/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/isotope/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 IsotopeSlateEditorFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"PM needs a concise migration note for IsotopeCloudReconcilerStore, 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":"IsotopeWrenExportCoordinator needs a paired pass: produce a consumer guide for IsotopeWrenExportCoordinator, plus give the existing implementation a read-only safety pass. Use projects/isotope/db/migrations/20260730_events.sql as the source of truth, preserve the SQLite contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Frost: The first IsotopeBirchMigratorFlow request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Garnet: Two asks around IsotopeAmberFilterCoordinator: (1) separate IsotopeAmberFilterCoordinator's policy from transport without behavior changes; (2) capture the contract and rollback note for consumers. Keep the patch readable for a small on-call review, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"A previously stable test around IsotopeDeltaCanvasFlow now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"IsotopeMosaicGridCoordinator: polish, then assess","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Harbor: Two asks around IsotopeFernSnapshotCoordinator: (1) assess ownership and failure handling in projects/isotope/apps/console/routes/usage.svelte; (2) capture the contract and rollback note for consumers. Keep the patch readable for a small on-call review, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-49148: retire the legacy replay path for IsotopePrismCacheFlow\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 IsotopePrismCacheFlow 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":"Split IsotopeOrbitSyncService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Clarify IsotopeMapleQueueService's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Compare IsotopeMosaicGridStore's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Translate the IsotopeEchoRegistryService setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The minimum supported WebGPU version in projects/isotope/Sources/App/SessionStore.swift 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":"Fresh release brief for IsotopeDriftConsoleCoordinator:\n- primary outcome: find the unknown cause of stale cursors when a page is resumed\n- companion outcome: correct the known stale timeout beside it\n- repository entry point: projects/isotope/services/ledger/replay.go\n- platform constraint: PostgreSQL 17\n- known complication: stale cursors when a page is resumed\n\nBoth results are required, but they should remain independently reviewable. Keep the patch readable for a small on-call review; 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":"debugging","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"UI ticket DES-49159: finish the compact IsotopeBirchMigratorCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/isotope/ui/settings/PrivacyPane.tsx\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\nBring IsotopeBirchMigratorCoordinator's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"IsotopeRavenSessionStore 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.6,"slice":"core","lang":"en"}
{"prompt":"Two engineers disagree about whether IsotopeCinderAuthFlow's cache is authoritative. Walk the reads and writes in projects/isotope/cmd/exporter/main.py and settle that question from the code. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Iris: Split projects/isotope/config/staging.toml by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Juniper: The public surface of IsotopeMapleQueueStore is frozen, but its internal ownership in projects/isotope/crates/index/src/segment.rs is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeMapleQueueStore\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows 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":"Two asks around IsotopeQuartzPlayerCoordinator: (1) lay out a staged migration for IsotopeQuartzPlayerCoordinator; (2) then implement the bounded durable-cursor handler. Keep the patch readable for a small on-call review, and leave a clear boundary between the resulting artifacts or edits.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Does IsotopeCopperBridgeStore enforce tenant scope before decoding its cursor, and could any early-return path reveal whether a foreign record exists? Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"We need to move IsotopeTideWorkerService from the legacy store to Tokio. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for IsotopeAcornWidgetStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"IsotopeLedgerGateCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"IsotopeSpruceDaemonCoordinator is blocking the next release because duplicate retries after a network handoff. I need two concrete outcomes from a single pass: find the unknown cause of duplicate retries after a network handoff, and capture the contract and rollback note for consumers. Use the existing PostgreSQL 17 conventions in projects/isotope/internal/auth/refresh.go; keep the patch readable for a small on-call review. 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":"debugging","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-49113\n\n08:02 deploy IsotopeWillowCodecFlow 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. From this evidence, draft consumer-facing migration guidance for IsotopeWillowCodecFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"IsotopeCraneWorkspaceCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Add a bounded IsotopeCloudReconcilerService 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":"Add a bounded IsotopePineMetricsService 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":"Compare IsotopeIrisBatchService's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'IsotopeWrenExportFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[IsotopeWrenExportFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/isotope/src/sync/reconcile.ts:144: error: -[IsotopeWrenExportFlowTests 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 '-[IsotopeWrenExportFlowTests 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 IsotopeWrenExportFlow'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":"The IsotopeCedarPolicyStore surface in projects/isotope/cmd/exporter/main.py is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Cadre la migration de IsotopeMarbleTokenService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"fr"}
{"prompt":"Test Suite 'IsotopeAtlasSearchFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[IsotopeAtlasSearchFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/isotope/Sources/App/SessionStore.swift:144: error: -[IsotopeAtlasSearchFlowTests 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 '-[IsotopeAtlasSearchFlowTests 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 IsotopeAtlasSearchFlow'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":"Release verification found a single stale IsotopeDriftConsoleStore value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- keep the patch readable for a small on-call review\n- retain the current PostgreSQL 17 operational envelope\n\nThis repository spans media encoding, Python ML, Windows; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: IsotopeEmberRelayService works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeEmberRelayService\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-49158: retire the legacy replay path for IsotopeLumenChartCoordinator\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 IsotopeLumenChartCoordinator 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":"En projects/isotope/packages/api/openapi.yaml, IsotopeBasilRunnerStore tiene un problema intermitente en el flujo de NATS JetStream. Propón fases, compatibilidad, métricas, rollback y ownership; detente antes de tocar código.\n\nRestricciones:\n- seguir con NATS JetStream\n- conservar compatibilidad y cancelación\n- limitar el cambio a IsotopeBasilRunnerStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con NATS JetStream alrededor de IsotopeBasilRunnerStore.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"es"}
{"prompt":"Summarize the IsotopeSlateEditorStore changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"IsotopeAtlasSearchService flakes under UTC","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Find IsotopeFernSnapshotStore's duplicate retry source","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Kestrel: Test Suite 'IsotopeTideWorkerFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[IsotopeTideWorkerFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/isotope/lib/codec/frame.cc:144: error: -[IsotopeTideWorkerFlowTests 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 '-[IsotopeTideWorkerFlowTests 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\nBring IsotopeTideWorkerFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/isotope/app/src/main/SyncWorker.kt b/projects/isotope/app/src/main/SyncWorker.kt\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/app/src/main/SyncWorker.kt\n+++ b/projects/isotope/app/src/main/SyncWorker.kt\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is IsotopeFernSnapshotFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Assess the IsotopeMosaicGridService diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Teach IsotopeOspreyJobService to verify signed continuation tokens, reject cross-tenant cursors, and rotate keys without invalidating tokens issued during the overlap window.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Lumen: diff --git a/projects/isotope/crates/index/src/segment.rs b/projects/isotope/crates/index/src/segment.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/crates/index/src/segment.rs\n+++ b/projects/isotope/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\nConsolidate IsotopeNovaPickerFlow'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":"Maple: Ticket OPS-49112: retire the legacy replay path for IsotopeEmberRelayFlow\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 IsotopeEmberRelayFlow 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":"Our support and SDK teams keep answering the same questions about IsotopeLumenChartStore, but the current prose in projects/isotope/db/migrations/20260730_events.sql only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing SQLite deployment\n- keep the work scoped to IsotopeLumenChartStore and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"projects/isotope/app/src/main/SyncWorker.kt 里的 IsotopeCraneWorkspaceStore 最近在 SQLite 流程中出现间歇性问题。 请阅读现有流程，判断 ownership、取消和顺序是否安全，只需要分析。\n\n约束：\n- 继续使用 SQLite\n- 保持兼容性和取消语义\n- 改动只限于 IsotopeCraneWorkspaceStore","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"zh"}
{"prompt":"Release engineering needs a IsotopeNovaPickerStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Flip IsotopeWrenExportService's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"IsotopeHarborIndexCoordinator: handle the lingering thing","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"IsotopeTideWorkerCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Korrigiere den IsotopeMarbleTokenStore-Timeout","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"de"}
{"prompt":"This should remain a deliberately small patch: IsotopeCinderAuthService has one known configuration mistake in projects/isotope/cmd/exporter/main.py, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing WebGPU deployment\n- keep the work scoped to IsotopeCinderAuthService and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Nimbus: The destination for IsotopeDeltaCanvasService is broadly agreed; the missing piece is a reversible route from projects/isotope/internal/auth/refresh.go to that target. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeDeltaCanvasService\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows 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":"Any races in IsotopeSummitProxyStore?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Sketch the IsotopeQuartzPlayerStore migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Opal: Test Suite 'IsotopeRainfallDBFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[IsotopeRainfallDBFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/isotope/db/migrations/20260730_events.sql:144: error: -[IsotopeRainfallDBFlowTests 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 '-[IsotopeRainfallDBFlowTests 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\nBring IsotopeRainfallDBFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/isotope/db/migrations/20260730_events.sql b/projects/isotope/db/migrations/20260730_events.sql\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/db/migrations/20260730_events.sql\n+++ b/projects/isotope/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\nRead the artifact above as a skeptical reviewer. Is IsotopeVelaDrawerFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"# projects/isotope/ml/pipeline/features.py\n[worker.isotopecinderauthcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.isotopecinderauthcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.isotopecinderauthcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.IsotopeCinderAuthCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-49157\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/isotope/ml/pipeline/features.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"IsotopeOspreyJobCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"IsotopeIrisBatchCoordinator: diagnose, then assess","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"What sequence would let IsotopeFlintTimelineStore adopt PostgreSQL 17 with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Prism: Two asks around IsotopeCoralUploadCoordinator: (1) lay out a staged migration for IsotopeCoralUploadCoordinator; (2) then implement the bounded durable-cursor handler. Keep the patch readable for a small on-call review, and leave a clear boundary between the resulting artifacts or edits.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Quartz: # projects/isotope/workers/thumbnail/consumer.ex\n[worker.isotopeacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.isotopeacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.isotopeacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.IsotopeAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-49129\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. Make the one confirmed configuration correction in projects/isotope/workers/thumbnail/consumer.ex. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Sketch the IsotopeAtlasSearchStore migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Dedupe IsotopeDriftConsoleService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-49111\n\n08:02 deploy IsotopeBasilRunnerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the IsotopeBasilRunnerFlow 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":"Two deliverables are holding up IsotopeEchoRegistryCoordinator. First, lay out a staged migration for IsotopeEchoRegistryCoordinator. In the same workstream, also add the visible loading and offline states. The relevant starting point is projects/isotope/lib/codec/frame.cc, which follows Tokio conventions and currently suffers from a misleading timeout name used in five packages. Keep the patch readable for a small on-call review.\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":"IsotopeFrostPanelStore's openapi.yaml needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"$ pnpm test --filter IsotopeNimbusFormCoordinator\n RUN v3.2.4 /workspace/apps/console\n × IsotopeNimbusFormCoordinator > 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=49153 phase=resume storedCursor=seg-0183\n session=49153 phase=fetch requestCursor=seg-0183 pageSize=200\n session=49153 phase=commit receivedCursor=seg-0184 itemCount=0\n session=49153 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\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Find the source of this IsotopeNimbusFormCoordinator symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"We need to move IsotopeRavenSessionFlow from the legacy store to Tokio. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"IsotopeRainfallDBCoordinator: give it a nicer flow","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Raven: Incident timeline — INC-49125\n\n08:02 deploy IsotopeOrbitSyncFlow 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 IsotopeOrbitSyncFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Give IsotopeNimbusFormStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"IsotopeHarborIndexStore'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":"Sable: projects/isotope/apps/console/routes/usage.svelte の IsotopeCraneWorkspaceService で、SQLite の flow に断続的な問題が起きています。 責務を分離して重複をなくし、API、wire value、順序、観測可能な動作は変えないでください。\n\n制約:\n- SQLite を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は IsotopeCraneWorkspaceService のみ","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Correct the IsotopeKiteSchedulerService flag default","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Bump IsotopeSlateEditorService's timeout to 30s","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a deadlock that appears only during shutdown in IsotopeRainfallDBStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Read projects/isotope/db/migrations/20260730_events.sql and tell me whether IsotopeRainfallDBService 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":"IsotopeOpalRouterCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Fresh release brief for IsotopeEmberRelayCoordinator:\n- primary outcome: lay out a staged migration for IsotopeEmberRelayCoordinator\n- companion outcome: then implement the bounded durable-cursor handler\n- repository entry point: projects/isotope/Sources/App/SessionStore.swift\n- platform constraint: WebGPU\n- known complication: two validators with subtly different error strings\n\nBoth results are required, but they should remain independently reviewable. Keep the patch readable for a small on-call review; 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":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Check IsotopeBeaconStoreService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"IsotopeCloudReconcilerCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-49117\n\n08:02 deploy IsotopeKiteSchedulerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the IsotopeKiteSchedulerFlow 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":"The public surface of IsotopeWillowCodecStore is frozen, but its internal ownership in projects/isotope/apps/console/routes/usage.svelte is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeWillowCodecStore\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows 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":"IsotopePineMetricsCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"In projects/isotope/config/staging.toml hat IsotopeBasilRunnerService ein sporadisches Problem im NATS JetStream-Ablauf. Verfasse eine Consumer-Doku mit Vertrag, Fehlern, Retry und einem kopierbaren Beispiel; ändere keinen Handler.\n\nRandbedingungen:\n- NATS JetStream weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf IsotopeBasilRunnerService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um IsotopeBasilRunnerService mit NATS JetStream kompatibel.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"Tide: // projects/isotope/apps/console/routes/usage.svelte\nfinal class IsotopeIrisBatchFlowCoordinator {\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 IsotopeIrisBatchFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"I inherited IsotopeKiteSchedulerStore and need a careful read of projects/isotope/cmd/exporter/main.py before I can sign off on the next release. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing WebGPU deployment\n- keep the work scoped to IsotopeKiteSchedulerStore and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.\n\nNothing is reported broken, so judge and explain current behavior without inventing a failure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"The first IsotopeOspreyJobStore request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"IsotopeNovaPickerCoordinator: polish the last piece","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/isotope/infra/modules/edge/main.tf b/projects/isotope/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/infra/modules/edge/main.tf\n+++ b/projects/isotope/infra/modules/edge/main.tf\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 IsotopeDeltaCanvasCoordinator by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"IsotopeJuniperCLICoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ownership of IsotopeEmberRelayStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep the patch readable for a small on-call review\n- retain the current WebGPU operational envelope\n\nThis repository spans media encoding, Python ML, Windows; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Umbra: Incident timeline — INC-49141\n\n08:02 deploy IsotopeAsterWebhookFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current IsotopeAsterWebhookFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about IsotopeEchoRegistryStore, but the current prose in projects/isotope/lib/codec/frame.cc only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing Tokio deployment\n- keep the work scoped to IsotopeEchoRegistryStore and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"En projects/isotope/apps/console/routes/usage.svelte, IsotopeNimbusFormService tiene un problema intermitente en el flujo de SQLite. Sigue queue, scheduler y cancelación, compara hipótesis y encuentra la causa antes de proponer cambios.\n\nRestricciones:\n- seguir con SQLite\n- conservar compatibilidad y cancelación\n- limitar el cambio a IsotopeNimbusFormService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"es"}
{"prompt":"projects/isotope/web/components/FilterDrawer.vue 里的 IsotopeJuniperCLIService 最近在 PostgreSQL 17 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 PostgreSQL 17\n- 保持兼容性和取消语义\n- 改动只限于 IsotopeJuniperCLIService","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"zh"}
{"prompt":"Milestones for replacing IsotopeWrenExportStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Flip IsotopeVelaDrawerStore's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Security flagged IsotopeBirchMigratorStore for a read-only pass because its Tokio boundary mixes tenant data, retries, and cancellation in subtle ways. 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- touch generated artifacts only through their checked-in generator\n- keep the patch readable for a small on-call review\n- retain the current Tokio operational envelope\n\nThis repository spans media encoding, Python ML, Windows; use its existing conventions rather than importing a new abstraction.\n\nNothing is reported broken, so judge and explain current behavior without inventing a failure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"IsotopePrismCacheCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"# CI job 49130: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: PostgreSQL 17\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] IsotopeQuartzPlayerFlowIntegration.replays_after_timeout ... ok\n[test] IsotopeQuartzPlayerFlowIntegration.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\nDeliver the IsotopeQuartzPlayerFlow 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":"Vela: // projects/isotope/engine/render/atlas.cpp\nfinal class IsotopeEchoRegistryFlowCoordinator {\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 IsotopeEchoRegistryFlow; 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":"Willow: diff --git a/projects/isotope/Sources/CLI/Commands/Doctor.swift b/projects/isotope/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/isotope/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\nWire IsotopeMoonlitSDKCoordinator's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about IsotopeGarnetModalService, but the current prose in projects/isotope/packages/api/openapi.yaml only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing NATS JetStream deployment\n- keep the work scoped to IsotopeGarnetModalService and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Xylem: # projects/isotope/engine/render/atlas.cpp\n[worker.isotoperavensessioncoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.isotoperavensessioncoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.isotoperavensessioncoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.IsotopeRavenSessionCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-49154\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/isotope/engine/render/atlas.cpp and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current IsotopeMicaProfileService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeMicaProfileService\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"IsotopeMapleQueueCoordinator: assess, then document","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"PM needs a concise migration note for IsotopeMicaProfileStore, 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":"IsotopeFrostPanelCoordinator needs a paired pass: find the unknown cause of stale cursors when a page is resumed, plus capture the contract and rollback note for consumers. Use projects/isotope/packages/api/openapi.yaml as the source of truth, preserve the NATS JetStream contract, and avoid unrelated cleanup.","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Yarrow: The IsotopeGarnetModalStore empty state in projects/isotope/config/staging.toml needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Zephyr: Incident timeline — INC-49147\n\n08:02 deploy IsotopeOspreyJobFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current IsotopeOspreyJobFlow 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":"Sequence IsotopeFernSnapshotService's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale IsotopeLumenChartService value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- keep the patch readable for a small on-call review\n- retain the current SQLite operational envelope\n\nThis repository spans media encoding, Python ML, Windows; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Memory attributed to IsotopeLedgerGateStore 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":"IsotopeCopperBridgeCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"PM is preparing the IsotopeBirchMigratorService rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeBirchMigratorService\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"IsotopeVelaDrawerCoordinator: polish, then assess","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Polish the IsotopeQuartzPlayerService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"One contained cleanup in projects/isotope/ui/settings/PrivacyPane.tsx: remove the obsolete IsotopeHarborIndexService import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Security flagged IsotopeMoonlitSDKService for a read-only pass because its WebGPU boundary mixes tenant data, retries, and cancellation in subtle ways. 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- touch generated artifacts only through their checked-in generator\n- keep the patch readable for a small on-call review\n- retain the current WebGPU operational envelope\n\nThis repository spans media encoding, Python ML, Windows; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"How does IsotopeOpalRouterService propagate cancellation through the PostgreSQL 17 boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-49110\n\n08:02 deploy IsotopeSpruceDaemonFlow 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\nReconstruct the IsotopeSpruceDaemonFlow 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":"Before we approve IsotopeTideWorkerStore, assess whether an accessibility label that reads the internal enum is an actual correctness risk or merely confusing structure. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Em projects/isotope/services/ledger/replay.go, o IsotopeJuniperCLIStore tem um problema intermitente no fluxo de PostgreSQL 17. Siga queue, scheduler e cancelamento, compare hipóteses e encontre a causa antes de mudar código.\n\nRestrições:\n- continuar com PostgreSQL 17\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao IsotopeJuniperCLIStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"pt"}
{"prompt":"diff --git a/projects/isotope/pkg/cache/lease.rs b/projects/isotope/pkg/cache/lease.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/pkg/cache/lease.rs\n+++ b/projects/isotope/pkg/cache/lease.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\nConsolidate IsotopeMapleQueueFlow'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":"Design handed over a final pass for IsotopeSpruceDaemonService, and the basic data flow in projects/isotope/infra/modules/edge/main.tf already works. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing PostgreSQL 17 deployment\n- keep the work scoped to IsotopeSpruceDaemonService and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"For IsotopeAcornWidgetCoordinator, assess ownership and failure handling in projects/isotope/ui/settings/PrivacyPane.tsx; once that is complete, capture the contract and rollback note for consumers. Work from projects/isotope/ui/settings/PrivacyPane.tsx, stay with Tokio, and keep the patch readable for a small on-call review. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Checkout: Incident timeline — INC-49131\n\n08:02 deploy IsotopeFrostPanelFlow 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 IsotopeFrostPanelFlow 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":"IsotopeDeltaCanvasStore's staging timeout is already known to be wrong: change the single projects/isotope/infra/modules/edge/main.tf value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-49135: finish the compact IsotopeJuniperCLIFlow filter experience\n\nRoute: /catalog/search\nSource: projects/isotope/web/components/FilterDrawer.vue\nFramework: PostgreSQL 17\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\nBring IsotopeJuniperCLIFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"IsotopeWillowCodecCoordinator is blocking the next release because memory growth during hour-long imports. I need two concrete outcomes from a single pass: produce a consumer guide for IsotopeWillowCodecCoordinator, and give the existing implementation a read-only safety pass. Use the existing SQLite conventions in projects/isotope/apps/console/routes/usage.svelte; keep the patch readable for a small on-call review. 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":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"For IsotopeBeaconStoreCoordinator, separate IsotopeBeaconStoreCoordinator's policy from transport without behavior changes; once that is complete, give the existing implementation a read-only safety pass. Work from projects/isotope/pkg/cache/lease.rs, stay with NATS JetStream, and keep the patch readable for a small on-call review. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"# projects/isotope/ml/pipeline/features.py\n[worker.isotopecedarpolicyflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.isotopecedarpolicyflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.isotopecedarpolicyflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.IsotopeCedarPolicyFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-49137\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Align IsotopeCedarPolicyFlow'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":"IsotopePrismCacheStore's staging timeout is already known to be wrong: change the single projects/isotope/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":"Style IsotopeSummitProxyService's offline state","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Drop IsotopeAmberFilterStore's unused import","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Give IsotopeAcornWidgetService a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-49136: retire the legacy replay path for IsotopePineMetricsFlow\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 IsotopePineMetricsFlow 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":"This should remain a deliberately small patch: IsotopeRavenSessionService has one known configuration mistake in projects/isotope/lib/codec/frame.cc, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing Tokio deployment\n- keep the work scoped to IsotopeRavenSessionService and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-49127\n\n08:02 deploy IsotopeCoralUploadFlow 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 IsotopeCoralUploadFlow 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.4,"slice":"pasted-context","lang":"en"}
{"prompt":"IsotopePrismCacheService 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":"Ticket OPS-49143: retire the legacy replay path for IsotopeCraneWorkspaceFlow\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 IsotopeCraneWorkspaceFlow 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":"Flip IsotopeBeaconStoreStore's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"The IsotopeCinderAuthStore empty state in projects/isotope/ml/pipeline/features.py needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"IsotopeAtlasSearchCoordinator: restructure, then correct","purpose":"refactor","secondary":"debugging","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/isotope/internal/auth/refresh.go b/projects/isotope/internal/auth/refresh.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/internal/auth/refresh.go\n+++ b/projects/isotope/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 IsotopeCopperBridgeFlow'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":"Exporter: Ticket OPS-49134: retire the legacy replay path for IsotopeLedgerGateFlow\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 IsotopeLedgerGateFlow, 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":"UI ticket DES-49149: finish the compact IsotopeSableParserFlow filter experience\n\nRoute: /catalog/search\nSource: projects/isotope/workers/thumbnail/consumer.ex\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 IsotopeSableParserFlow's compact and accessibility behavior, including focus restoration, large text, offline recovery, and honest loading feedback.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Scheduler: Ticket OPS-49120: retire the legacy replay path for IsotopeSummitProxyFlow\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 IsotopeSummitProxyFlow 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":"core","lang":"en"}
{"prompt":"Is there a cleaner way to separate IsotopeSableParserStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Check IsotopeVelaDrawerService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Dashboard: For IsotopeSlateEditorCoordinator, change IsotopeSlateEditorCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, give the existing implementation a read-only safety pass. Work from projects/isotope/Sources/App/SessionStore.swift, stay with WebGPU, and keep the patch readable for a small on-call review. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Worker: diff --git a/projects/isotope/pkg/cache/lease.rs b/projects/isotope/pkg/cache/lease.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/pkg/cache/lease.rs\n+++ b/projects/isotope/pkg/cache/lease.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 IsotopeMicaProfileCoordinator 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":"Our support and SDK teams keep answering the same questions about IsotopeWillowCodecService, but the current prose in projects/isotope/app/src/main/SyncWorker.kt only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- keep the patch readable for a small on-call review\n- stay compatible with the existing SQLite deployment\n- keep the work scoped to IsotopeWillowCodecService and its direct tests\n\nThe relevant code crosses media encoding, Python ML, Windows. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"IsotopeOrbitSyncCoordinator needs a paired pass: produce a consumer guide for IsotopeOrbitSyncCoordinator, plus give the existing implementation a read-only safety pass. Use projects/isotope/web/components/FilterDrawer.vue as the source of truth, preserve the PostgreSQL 17 contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Simulator: PM is preparing the IsotopeSpruceDaemonStore rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside IsotopeSpruceDaemonStore\n- keep the patch readable for a small on-call review\n\nSeveral teams work in this media encoding, Python ML, Windows monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for IsotopeFrostPanelService","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Could IsotopeCopperBridgeService show the active PostgreSQL 17 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":"Runbook: diff --git a/projects/isotope/web/components/FilterDrawer.vue b/projects/isotope/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/isotope/web/components/FilterDrawer.vue\n+++ b/projects/isotope/web/components/FilterDrawer.vue\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is IsotopeDriftConsoleFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"IsotopeMarbleTokenCoordinator: sequence, then restructure","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"// projects/isotope/packages/api/openapi.yaml\nfinal class IsotopeMosaicGridFlowCoordinator {\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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Deliver the IsotopeMosaicGridFlow 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":"Trace: Ticket OPS-49119: retire the legacy replay path for IsotopeMarbleTokenFlow\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 IsotopeMarbleTokenFlow 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":"A copied hex color in IsotopeNimbusFormFlow lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up IsotopeBasilRunnerCoordinator. First, separate IsotopeBasilRunnerCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/isotope/packages/api/openapi.yaml, which follows NATS JetStream conventions and currently suffers from a query plan that changes after statistics refresh. Keep the patch readable for a small on-call review.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Profiler: Incident timeline — INC-49145\n\n08:02 deploy IsotopeOpalRouterFlow 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，并明确说明证据和取舍。 Using this as the starting evidence, propose a staged IsotopeOpalRouterFlow 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":"IsotopeAsterWebhookCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"IsotopeLumenChartFlow 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":"IsotopeCoralUploadService é seguro?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"pt"}
{"prompt":"Console: // projects/isotope/config/staging.toml\nfinal class IsotopeGarnetModalCoordinatorCoordinator {\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 IsotopeGarnetModalCoordinator 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":"A previously stable test around IsotopeMicaProfileFlow now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Teach IsotopeAsterWebhookService to verify signed continuation tokens, reject cross-tenant cursors, and rotate keys without invalidating tokens issued during the overlap window.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Workspace: projects/isotope/crates/index/src/segment.rs now contains IsotopePineMetricsStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Document IsotopeOrbitSyncStore's cancellation rules","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Documente le contrat IsotopeCoralUploadStore","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"The first IsotopeSableParserService request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"IsotopeCedarPolicyCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Repository: The name pendingAck means two different things across IsotopeMoonlitSDKStore's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Pipeline: // projects/isotope/web/components/FilterDrawer.vue\nfinal class IsotopeFlintTimelineCoordinatorCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate IsotopeFlintTimelineCoordinator'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"}
data/round2-10.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "the agent stops reporting on some hosts after a kernel upgrade:\n\nlevel=info msg=\"loading eBPF programs\" kernel=6.11.0-19-generic btf=/sys/kernel/btf/vmlinux\nlevel=error msg=\"failed to load program\" prog=tcp_connect err=\"field Sport: can't resolve field: not found\"\nlevel=error msg=\"failed to load program\" prog=tcp_close err=\"field Sport: can't resolve field: not found\"\nlevel=warn msg=\"falling back to procfs polling\" interval=10s\nlevel=info msg=\"agent started\" mode=degraded programs_loaded=3/9\n\nsame binary, same config, works on 6.8 hosts. the struct sock layout changed and we compile with CO-RE, which was supposed to handle exactly this", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "agent CPU spikes to a full core on hosts with many containers and stays there:\n\nperf top -p 41221:\n 38.11% [kernel] [k] bpf_prog_a11c3f2_tcp_connect\n 21.44% agent [.] lumen/agent/proc.(*Resolver).containerFor\n 14.02% agent [.] runtime.mapaccess2_faststr\n 9.88% agent [.] os.ReadFile\n 4.11% [kernel] [k] __d_lookup\n\ncontainerFor reads /proc/<pid>/cgroup on every event and parses it; the host runs 400 containers and about 12,000 events a second", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "our go modules define three `Meta` types that are converted between at every boundary", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "listing search returns nothing for one region and the logs are unhelpful:\n\nElasticsearch::Transport::Transport::Errors::BadRequest ([400] {\"error\":{\"root_cause\":[{\"type\":\"query_shard_exception\",\"reason\":\"failed to create query: [geo_bounding_box] field [location] is not a geo_point field\"}],\"type\":\"search_phase_execution_exception\",\"phase\":\"query\",\"grouped\":true}})\n app/queries/listing_search.rb:88:in `execute'\n app/controllers/api/v3/listings_controller.rb:22:in `index'\n\nindex mapping for listings-2026-07:\n \"location\": { \"type\": \"object\", \"properties\": { \"lat\": {\"type\":\"float\"}, \"lon\": {\"type\":\"float\"} } }\n\nindex mapping for listings-2026-06:\n \"location\": { \"type\": \"geo_point\" }\n\nthe july index was created by a rollover after someone deleted the index template last month", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "agent's memory grows on busy hosts until the OOM killer takes it:\n\nrss: 180MB → 2.1GB over 4 hours\nbpf map usage:\n connections max_entries=65536 current=65536 (full)\n sockets max_entries=65536 current=65536 (full)\n events (ringbuf) 16MB, consumer lag 14MB\n\ngo heap profile:\n flat flat% cum cum%\n 1.4GB 62.1% 1.4GB 62.1% lumen/agent/enrich.(*Cache).Put\n 0.4GB 17.8% 0.4GB 17.8% encoding/json.Marshal\n\nCache is keyed by (pid, fd) with no eviction, and on this host processes churn thousands of short-lived connections a second", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "agent config across environments, and only prod fills its maps:\n\n# staging\nmap_sizes: { connections: 65536, sockets: 65536 }\nsample_rate: 1.0\nenrich: { container: true, k8s: false, process_tree: false }\ncpu_limit_percent: 10\nhosts: 40\n\n# prod\nmap_sizes: { connections: 65536, sockets: 65536 }\nsample_rate: 1.0\nenrich: { container: true, k8s: true, process_tree: true }\ncpu_limit_percent: 10\nhosts: 40000\n\nstaging hosts run 5 containers each, prod hosts run up to 400, and process_tree is the option that doubles memory", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "the map screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "our API changelog needs an entry for the fixed page size and what partners should do about it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "saved searches fire notifications for listings that don't match, here's one:\n\nsaved_search 4471:\n bbox: [-0.21, 51.48, -0.09, 51.53]\n min_beds: 2\n max_price_cents: 65000000\n property_type: [\"flat\", \"maisonette\"]\n\nlisting 88412 that triggered it:\n location: { lat: 51.61, lon: -0.19 }\n beds: 2\n price_cents: 62000000\n property_type: \"house\"\n\nthe matcher runs as a percolator query built from the saved search, and both the bbox and the type are wrong here", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "what does the ringbuffer do when full?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a customer needs the agent on 5.4 kernels, which we dropped in 2.4 because CO-RE and ring buffers made everything simpler. i'd like an honest view of what supporting them again costs — a compatibility layer, a separate build, or declining the business — and what it means for the next two years of kernel support the deal is worth about a fifth of our ARR, so \"no\" needs to be well argued.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "agent's configuration, which customers deploy across their fleets with no documentation beyond a sample file:\n\nagent:\n endpoint: https://ingest.lumen.io\n tenant_key: <secret>\n sample_rate: 1.0 # events per second per process, 0 disables\n programs: [tcp, dns, file, exec]\n map_sizes: { connections: 65536, sockets: 65536 }\n ringbuf_bytes: 16777216\n enrich: { container: true, k8s: true, process_tree: false }\n fallback_procfs: true\n cpu_limit_percent: 10\n\nthings only we know: sample_rate is per process, not per host, so a host with 500 processes is not sampled at all; cpu_limit_percent is advisory and enforced by our own scheduler, not cgroups; map_sizes above 65536 need a kernel with BPF_MAP_TYPE_LRU_HASH support; and turning on process_tree roughly doubles memory", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "listing count says \"1 results\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "compiler miscompiles one function under -O2 and i've reduced it this far:\n\nerror: internal compiler error: broken MIR in Item DefId(0:412 ~ lumenc[a11c]::opt::fold)\n --> src/opt/fold.rs:141:9\n |\n141| let folded = self.fold_const(expr)?;\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n = note: value of type `ConstValue` has no in-memory representation\n\nthread 'rustc' panicked at compiler/rustc_middle/src/ty/consts.rs:88:22:\nassertion failed: !ty.has_infer()\nstack backtrace:\n 0: rust_begin_unwind\n 4: lumenc::opt::fold::ConstFolder::fold_binary\n 5: lumenc::opt::run_passes\n\nonly with our own const-folding pass enabled, and only when the input has a shift by a value we can't prove is in range", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "compiler's incremental builds are wrong about one in fifty times and it's terrifying:\n\n$ lumenc build\n Compiling app v0.4.1\n Finished in 2.1s\n$ ./target/app\nsegmentation fault\n\n$ lumenc build --no-incremental\n Compiling app v0.4.1\n Finished in 41.2s\n$ ./target/app\nok\n\nfingerprint debug output for the changed module:\n src/render.lm mtime=1753843201 size=8412 hash=9c1d0044 deps=[math, gfx]\n cached fingerprint: mtime=1753843201 size=8412 hash=9c1d0044 deps=[math]\n\nthe dependency list changed but the hash didn't, because the hash covers the source text and not the resolved imports", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "three services build the same \"is this listing visible\" condition and they disagree:\n\n# api/v3/listings_controller.rb\nscope.where(status: %w[live under_offer]).where(published_at: ..Time.current)\n\n# jobs/portal_feed_job.rb\nscope.where(status: \"live\").where.not(published_at: nil)\n\n# app/queries/saved_search_matcher.rb\nscope.where(\"status != 'withdrawn'\").where(\"published_at IS NOT NULL\")\n\nthe first includes under-offer listings, the second excludes them, and the third includes drafts that happen to have a published_at from a previous publish", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "pass manager has grown conditionals for every pass we've added. same output, better structure:\n\npub fn run_passes(module: &mut Module, opts: &Opts) {\n if opts.opt_level >= 1 { inline::run(module, opts.inline_threshold); }\n if opts.opt_level >= 1 && !opts.no_const_fold { fold::run(module); }\n if opts.opt_level >= 2 { \n loop_opt::run(module);\n if !opts.no_vectorize && module.target.has_simd() { vectorize::run(module); }\n }\n if opts.debug_assertions { assert_checks::run(module); }\n if opts.opt_level >= 2 && opts.lto { cross_module::run(module); }\n if opts.opt_level >= 1 { dce::run(module); }\n if opts.emit_ir { dump_ir(module); }\n if opts.opt_level >= 2 { fold::run(module); } // second fold, added later, nobody remembers why\n}", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "portal partner's feed specification, which we produce:\n\nnightly full feed plus a delta feed every 15 minutes\n full: gzipped NDJSON, one listing per line, uploaded to their SFTP by 05:00\n delta: same shape, only listings changed since the last delta, plus a `deleted` array of ids\n a listing that is withdrawn must appear in `deleted`, not merely be absent\n price changes must produce a delta entry, which today they do not because price lives in a separate table with its own timestamp\n every entry needs a stable `source_id` that survives a listing being unpublished and republished\n they process deltas in order and will reject a delta whose sequence number is not consecutive\n if we miss a delta window, the next one must include everything since the last successful one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "one visibility scope for listings", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "is that transmute actually sound?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "incremental compilation is wrong about one build in fifty and the cause is that fingerprints hash source text but not the resolved dependency set, which the original RFC explicitly rejected as expensive. i want the fix designed properly — what goes into a fingerprint, how we invalidate the existing caches on upgrade, and how we'd detect a recurrence in CI rather than in a customer's production binary two customers have shipped a binary built this way, which is the part that keeps me up.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "i'd like an honest read of whether a plugin can crash the compiler with an out-of-range span, and if so the validation that stops it — with a test that used to crash i'd like enough detail that i can hand it to someone else to finish.", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "a prospect's security team has asked six pointed questions about what the agent collects, what happens when our endpoint is unreachable, and the blast radius of a bad eBPF program. answer each from the code and write it as a page we can publish, rather than an email that gets forwarded and misquoted they will forward whatever we write to their own security review, so it has to survive being read carefully.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "saved searches notify on listings that match neither the bounding box nor the property type, which suggests the percolator query is built from stale saved-search fields. diagnose it, then fix the builder", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "what happens to buffered events when the agent is restarted mid-upload", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "react native app crashes when returning from the camera on android 15 only:\n\nFATAL EXCEPTION: main\nProcess: com.lumen.estate, PID: 8812\njava.lang.RuntimeException: Unable to resume activity {com.lumen.estate/com.lumen.estate.MainActivity}: java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState\n\tat android.app.ActivityThread.performResumeActivity(ActivityThread.java:5412)\n\tat androidx.fragment.app.FragmentManager.checkStateLoss(FragmentManager.java:1882)\n\tat com.lumen.estate.photos.PhotoPickerModule.onActivityResult(PhotoPickerModule.java:141)\n\nonly when the system killed our activity while the camera was open, which android 15 does far more aggressively", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "before this goes in, is the unsafe block justified or are we fooling ourselves?\n\npub fn intern(&self, s: &str) -> Symbol {\n if let Some(&sym) = self.map.borrow().get(s) {\n return sym;\n }\n let owned = s.to_owned();\n let leaked: &'static str = unsafe { std::mem::transmute::<&str, &'static str>(&owned) };\n std::mem::forget(owned);\n let sym = Symbol(self.strings.borrow().len() as u32);\n self.strings.borrow_mut().push(leaked);\n self.map.borrow_mut().insert(leaked, sym);\n sym\n}\n\nthe interner is per-compilation-session, sessions are dropped between builds in the language server, and the language server is long-lived", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "eBPF program's map handling, which i'd like a second opinion on before we ship it widely:\n\nSEC(\"kprobe/tcp_connect\")\nint BPF_KPROBE(tcp_connect, struct sock *sk) {\n struct conn_key key = {};\n key.pid = bpf_get_current_pid_tgid() >> 32;\n BPF_CORE_READ_INTO(&key.sport, sk, __sk_common.skc_num);\n BPF_CORE_READ_INTO(&key.daddr, sk, __sk_common.skc_daddr);\n\n struct conn_val val = {};\n val.ts = bpf_ktime_get_ns();\n bpf_map_update_elem(&connections, &key, &val, BPF_ANY);\n\n struct event *e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);\n if (!e) return 0;\n e->pid = key.pid;\n bpf_ringbuf_submit(e, 0);\n return 0;\n}\n\nthe connections map is a hash with 65536 entries and nothing deletes from it except a userspace sweep every 30 seconds", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "por favor revisa la consulta de búsqueda antes de que la pongamos en producción:\n\ndef execute\n Listing.search(\n query: {\n bool: {\n must: [{ match: { description: params[:q] } }],\n filter: [\n { geo_bounding_box: { location: bbox_from(params) } },\n { range: { price_cents: { lte: params[:max_price] } } },\n { terms: { property_type: params[:types] } }\n ]\n }\n },\n size: params.fetch(:size, 50),\n sort: [{ _score: :desc }, { listed_at: :desc }]\n )\nend\n\nparams[:types] llega directamente del cliente sin validar, size no tiene límite superior, y el índice tiene 4 millones de anuncios", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "es"}
{"prompt": "photo pipeline, three lambdas that grew separately. worth a read before i extend it:\n\nupload-handler: validates content-type, writes to s3://raw/, publishes to SNS\nthumbnail-worker: sharp().resize(1200).jpeg({quality: 80}).toBuffer() → s3://thumbs/\nfloorplan-worker: detects floorplans by filename heuristic (\"plan\" in the name), applies OCR, writes JSON\n\nnone of them read EXIF; the thumbnail worker strips all metadata; the floorplan heuristic misfires on any listing whose address contains \"plan\"; and a failure in any of them leaves the listing in \"processing\" forever because the state is only advanced on success", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "mobile app's offline handling for saved listings, which i suspect is why favourites go missing:\n\nconst save = async (listing: Listing) => {\n const current = JSON.parse((await AsyncStorage.getItem('saved')) ?? '[]')\n const next = [...current, listing]\n await AsyncStorage.setItem('saved', JSON.stringify(next))\n try {\n await api.post('/saved', { listingId: listing.id })\n } catch {\n // will sync later\n }\n}\n\nthere is no \"sync later\"; the app also fetches the server list on launch and overwrites AsyncStorage with it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the agent, from the commits since 2.4:\n\n41c9e0b fix(ebpf): CO-RE relocation for struct sock on 6.11 kernels\n88f21c0 feat(maps): LRU hash for the connections map, evicting instead of filling\nc0aa774 perf(enrich): cache container lookups per cgroup id instead of per event\n2e91b45 fix(sample): sample_rate is now per host, not per process\naa30f19 feat(config): cpu_limit_percent enforced via cgroups where available\n9c1d004 chore: minimum kernel is now 5.10\n4410bb7 fix(ringbuf): drop oldest instead of blocking when the consumer is behind\nb77e910 feat(k8s): pod and namespace enrichment from the kubelet API\n\nour readers are platform engineers deploying this to fleets; two of these change behaviour they've built alerts around", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "CI for the compiler takes 40 minutes and this is the whole config:\n\njobs:\n test:\n strategy:\n matrix:\n os: [ubuntu-24.04, macos-15, windows-2022]\n steps:\n - uses: actions/checkout@v4\n - uses: dtolnay/[email protected]\n - run: cargo test --all-features\n - run: cargo test --release --all-features\n - run: ./scripts/run_ui_tests.sh\n - run: cargo bench --no-run\n\nno caching of any kind, the release test run duplicates the debug one for most tests, and the ui test script rebuilds the compiler from scratch", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "unsere React-Native-Screens holen ihre Daten jeweils selbst, mit drei verschiedenen Mustern:\n\n// ListingScreen.tsx\nuseEffect(() => { api.get(`/listings/${id}`).then(setListing) }, [id])\n\n// SavedScreen.tsx\nconst { data } = useQuery({ queryKey: ['saved'], queryFn: fetchSaved })\n\n// SearchScreen.tsx\nconst [state, dispatch] = useReducer(searchReducer, initial)\nuseEffect(() => { let cancelled = false; search(state.filters).then(r => !cancelled && dispatch({type:'ok', r})); return () => { cancelled = true } }, [state.filters])\n\ndrei Muster, drei Fehlerbehandlungen, und nur eines davon behandelt den Offline-Fall überhaupt", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "de"}
{"prompt": "design spec for the map search screen, react native, which is our most-used surface:\n\nMap search\n- Map fills the screen; a bottom sheet at three detents holds the result list, snapping to peek / half / full.\n- Clusters above 12 listings show a count; below that, individual pins priced in thousands (\"£625k\").\n- Panning refetches with a 400ms debounce and a \"Search this area\" button rather than automatic refetch — users hated automatic.\n- Selected pin lifts, turns accent, and scrolls the sheet to that listing without changing the detent.\n- Saved listings show a filled heart on the pin; toggling from the sheet updates the pin immediately and reconciles later.\n- Offline: last results and their photos are shown with a banner; the search button is disabled with an explanation.\n- Accessibility: every pin reachable by the list, which is the accessible path; the map itself is marked as decorative.\n- Must hold 60fps while panning with 300 pins on a mid-range android device from 2021.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "price arrows are colour-only", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "why is incremental sometimes wrong?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "two of the three compiler engineers leave in six weeks and the remaining list includes a soundness landmine, a correctness bug and a pile of ergonomics work. sequence it with the departures as the main constraint, and tell me plainly which item is the most dangerous thing to leave undocumented rather than merely undone the person joining in october has no context on any of this.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "listings stuck in processing generate about forty support calls a week and the fix is always the same re-upload. write the troubleshooting page support can follow, and separately tell me which of the six behaviours in my notes are product bugs that documentation would merely paper over support has no engineering access, so every step has to be something they can do themselves.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "fleet view has to stay usable when the control plane itself is degraded, which today means it shows a spinner forever. rebuild it to the spec with stale data marked by age, filters in the URL, and bulk actions that say how many hosts they will touch before they do it during an incident this screen is the only thing platform engineers trust, so stale-but-labelled beats empty.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "viewing booking service does eight things in one method and only the availability check needs to be transactional. split it, then document the new boundaries and what is guaranteed to have happened by the time the API returns this has come up in three separate reviews now and never gets done.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "agents stopped loading three eBPF programs after a kernel upgrade despite CO-RE, which is exactly what CO-RE was meant to prevent. work out why the relocation failed, then fix it so the next kernel doesn't do this to us assume whoever picks this up next has no context at all. assume whoever picks it up next has no context beyond what you write.", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "compiler's error messages are inconsistent and i want a house style before we add fifty more. current examples:\n\nerror: type mismatch\nerror: expected `Int`, found `String`\nerror[E0412]: cannot find type `Foo` in this scope\nERROR: unresolved import `std::collectionz`\nerror: the trait bound `T: Display` is not satisfied\nwarning: unused variable x\nnote: `Bar` is defined here but not exported\n\ninconsistent: capitalisation, whether codes are used, whether the primary message names the file, whether we suggest a fix, and whether we use backticks around identifiers\n\nwrite the error message style guide, with rules for wording, structure, spans, notes and suggestions, and rewrite these seven as examples", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "compiler team's list, and one of them is leaving in six weeks:\n\n- incremental fingerprints must include the resolved dependency set, which is the correctness bug\n- error messages need a house style and a lint that enforces it\n- the interner's unsafe transmute is a landmine in the language server\n- plugin diagnostics can crash the compiler with an out-of-range span\n- the second const-fold pass exists for a reason nobody remembers and removing it changes output\n- ui tests take 20 of our 40 CI minutes and rebuild the compiler from scratch\n\nsequence these with the departure in mind, and say plainly which one is the highest risk to leave undone", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "pass manager as an ordered list", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "one cache layer in the agent", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "portal feed shows withdrawn listings for hours and misses price changes entirely, because price lives in a separate table with its own timestamp and the feed keys on the listing's updated_at. before we patch it i'd like a view on whether the feed should be event-driven rather than diff-driven, and what that means for partners who process deltas in strict sequence partners process deltas strictly in sequence and reject anything with a gap.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "incremental fingerprint RFC rejected hashing the resolved dependency set as rarely different, which is exactly the case that has now miscompiled production code twice. read the RFC against the current implementation and tell me which of its other assumptions are similarly optimistic i'd rather find the rest of them now than after the next miscompile. flag anything you'd want to change before doing it rather than after.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "three services each define what makes a listing visible and they disagree about under-offer, drafts with a stale published_at, and withdrawn listings. settle on one definition, apply it in all three, and give me the list of listings whose visibility changes so the content team can be warned before partners notice the portal feed is the one partners see, so it's the definition that matters most externally.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand what the second const-fold pass changes, since removing it alters output", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "the agent has three caches with three lifetimes, one unbounded, one re-read from procfs on every event, and one that isn't really a cache. consolidate them behind one layer with explicit bounds and eviction, and keep the enrichment output identical for a recorded hour of events from a busy host a recorded hour from the four-hundred-container host is in the fixtures bucket for comparison.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "agent degrades after the kernel upgrade", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our health endpoint reports the agent healthy while it's in procfs fallback with three programs unloaded", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "listing thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "agent's enrichment cache and the process resolver both key on things that churn:\n\n// enrich/cache.go\ntype Cache struct { m map[connKey]*Meta } // keyed by (pid, fd), never evicted\n\n// proc/resolver.go\nfunc (r *Resolver) containerFor(pid uint32) string {\n b, _ := os.ReadFile(fmt.Sprintf(\"/proc/%d/cgroup\", pid)) // on every event\n return parseCgroup(b)\n}\n\n// k8s/enricher.go\nfunc (e *Enricher) podFor(containerID string) *Pod {\n return e.byContainer[containerID] // refreshed every 30s from the kubelet\n}\n\nthree caches with three lifetimes, one of which is unbounded and one of which isn't a cache at all", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "agent stuff again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "the listing gallery should preload the next two images while the current one is showing", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "our language server and compiler share a crate that assumes one compilation per process", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "is our percolator matcher using the saved search as stored or as it was when created", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does the delta feed make if we miss a fifteen-minute window entirely", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "a walkthrough of how a viewing reaches the agent's calendar would help before i touch sync", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "agent's sampling is per process at a fixed rate, so a host with five hundred processes is effectively unsampled, and when the ringbuffer fills the kernel silently overwrites exactly the events we most want. work through what adaptive sampling with per-category floors would require, including the awkward fact that customers alert on raw event counts today one customer alerts on events per host per minute and would notice adaptive sampling immediately.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "listing page fails seven accessibility items including a carousel that only responds to swipe. fix them, and write the accessibility statement the portal partner asked for", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "saved searches need an edit screen that shows what the search currently matches before saving", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "les photos des annonces arrivent parfois pivotées de 90 degrés, mais seulement depuis l'app iOS :\n\nfichier reçu : IMG_4471.HEIC, 4032x3024\nEXIF Orientation: 6 (rotate 90 CW)\npipeline de traitement :\n 1. upload direct vers S3 (pas de transformation)\n 2. lambda de vignettes : sharp().resize(1200).jpeg().toBuffer()\n 3. écriture de la vignette, 1200x900\n 4. l'app web affiche la vignette\n\nles vignettes générées perdent l'orientation EXIF et sharp n'est pas configuré avec rotate(); le web affiche donc l'image couchée alors que l'original est correct", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "fr"}
{"prompt": "booking-viewing flow double-books slots occasionally and the audit trail looks like this:\n\n11:02:14.101 POST /viewings agent=a_881 listing=88412 slot=2026-08-03T14:00Z → 201 viewing v_4471\n11:02:14.118 POST /viewings agent=a_902 listing=88412 slot=2026-08-03T14:00Z → 201 viewing v_4472\n11:02:14.140 slot_availability recalculated for listing 88412: 14:00 marked unavailable\n11:02:14.155 notification sent to vendor: 2 viewings booked at 14:00\n\nthe controller checks availability with a SELECT and then inserts, no unique index on (listing_id, slot), and availability is a materialised view refreshed after the fact", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "availability logic behind viewing bookings, which i inherited:\n\ndef available_slots(listing, from_date, to_date)\n slots = listing.vendor.availability_windows.flat_map { |w| w.slots_between(from_date, to_date) }\n booked = Viewing.where(listing: listing, starts_at: from_date..to_date).pluck(:starts_at)\n blocked = listing.blackouts.where(date: from_date..to_date).flat_map(&:slots)\n (slots - booked - blocked).sort\nend\n\ncalled from the API on every listing page view, from the notification job, and from the agent app's calendar sync; vendors edit their availability windows from a separate screen with no locking", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "RFC for our incremental compilation fingerprints. does it actually close the hole we hit?\n\n## Fingerprints\nEach module's fingerprint is the hash of its source text. A module is recompiled when its fingerprint changes or when any of its dependencies were recompiled.\n\n## Rationale\nSource text is cheap to hash and captures every change a user can make.\n\n## Known gaps\n- Changes to compiler flags are not captured; users are told to run a clean build.\n- The dependency graph is recorded from the previous build.\n\n## Rejected\nHashing the resolved dependency set was rejected as \"expensive and rarely different\".", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "query the agent's control plane runs every 30 seconds for every tenant:\n\nSELECT h.id, h.hostname, h.last_seen_at, h.agent_version,\n count(distinct c.id) FILTER (WHERE c.state = 'running') AS containers,\n (SELECT count(*) FROM events e WHERE e.host_id = h.id AND e.ts > now() - interval '5 minutes') AS recent_events,\n (SELECT max(ts) FROM events e2 WHERE e2.host_id = h.id) AS last_event\nFROM hosts h\nLEFT JOIN containers c ON c.host_id = h.id\nWHERE h.tenant_id = $1 AND h.deleted_at IS NULL\nGROUP BY h.id;\n\n40,000 hosts across tenants, events is 2.1 billion rows partitioned by day, and this runs per tenant per 30 seconds", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "support notes about listings stuck in processing, which need to become a real page:\n\n- a listing goes to \"processing\" when photos are uploaded and leaves it when all workers report success\n- if any worker fails, the listing stays in processing forever and the agent sees no error\n- the most common failure is a HEIC the thumbnail worker can't decode, about 40 a week\n- support fixes it by re-uploading the photo, which starts the pipeline again\n- there's a script that force-advances a listing, which two people know about\n- agents phone in because the listing isn't live and they have a viewing booked\n\nwrite the support-facing troubleshooting page, and separately note which of these are product bugs rather than documentation gaps", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "die Notizen aus der Störung von gestern, daraus soll die Kundenmitteilung werden:\n\n14:02 Kunden melden, dass in einer Region keine Suchergebnisse erscheinen\n14:18 bestätigt: alle Abfragen mit Kartenausschnitt schlagen fehl, Textsuche funktioniert\n14:35 Ursache gefunden: der neue Index vom 1. Juli hat kein geo_point-Mapping\n14:50 Index-Template war im Juni versehentlich gelöscht worden\n15:20 Reindexierung gestartet, 4,1 Millionen Anzeigen\n17:40 Reindexierung abgeschlossen, Suche wieder normal\n\nBetroffen war eine Region, dreieinhalb Stunden lang; keine Daten verloren, aber Makler konnten ihre eigenen Anzeigen nicht finden und haben teilweise doppelt eingestellt", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "de"}
{"prompt": "vendor's questions before they sign, which we should answer as documentation rather than an email:\n\n\"What data does the agent collect from our hosts, exactly? Does it read file contents or only metadata? Are command-line arguments captured, and if so can we redact them? What happens to the agent if your ingest endpoint is unreachable for a day — does it buffer, drop, or fill our disk? Can we run it in a mode that collects nothing until we've reviewed the schema? What is the blast radius if one of your eBPF programs has a bug on a production kernel?\"\n\nanswer each from the code and write it as a page we can publish", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "marketplace's public API, which three portal partners integrate against off a README from 2024:\n\nGET /api/v3/listings\n filters: bbox, min_price, max_price, min_beds, property_type[], status\n sort: price_asc | price_desc | listed_desc | relevance (default relevance, which needs `q`)\n pagination: cursor-based, `after` opaque, page size 50 fixed\n a listing under offer is returned with status=under_offer unless `status` excludes it\n withdrawn listings disappear entirely, which partners handle badly — they keep showing them\n the price on a listing can change without the listing changing its updated_at, because price lives in a separate table\n\nwrite the reference, and be explicit about the updated_at problem because it's why partners' caches go stale", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "runbook for a stuck ingest pipeline is a slack thread. what we actually do:\n\n- symptom is agents reporting fine but events not appearing for a tenant\n- first check is the per-tenant kafka lag dashboard; over 5 minutes of lag means the consumer is behind\n- if lag is flat and high, the enrichment stage is stuck on a slow k8s API; restarting the enricher clears it\n- if lag is climbing steadily, it's usually one tenant sending 100x their normal volume\n- `lumenctl tenant throttle <id> --rate 5000` slows them without dropping, and we tell the account manager afterwards\n- never restart the ingest tier during business hours; it drops the ringbuffer contents on every agent connected to it\n\nwrite the runbook page, in the order someone paged at 3am would need it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "我们的编译器诊断文档只有一页示例，第三方插件作者一直在猜。当前实际行为：\n\n- 诊断分为 error / warning / note 三级，note 不能单独出现，必须挂在前两者下面\n- 错误码格式是 `E0412`，但只有大约三分之一的诊断有码，其余没有，也没有规则说明什么时候该有\n- span 支持多段，但渲染时只显示第一段所在的文件，跨文件的诊断会丢失上下文\n- 建议（suggestion）分为 machine-applicable 和 maybe-incorrect，前者会被 `--fix` 自动应用\n- 插件返回的诊断不做校验，span 越界会导致编译器崩溃而不是报错\n- 同一位置的多条诊断按插件注册顺序输出，没有去重\n\n示例代码：\n\nDiagnostic::error(\"type mismatch\")\n .with_span(span, \"expected `Int`, found `String`\")\n .with_note(\"the function signature is defined here\")\n .emit();\n\n请写成给插件作者的诊断 API 文档，把错误码规则和 span 越界这两点写清楚", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "zh"}
{"prompt": "rubocop and the type checker on the rails app, gate goes on friday:\n\napp/queries/listing_search.rb:88:5: C: Metrics/MethodLength: Method has too many lines. [31/15]\napp/queries/listing_search.rb:41:9: W: Lint/UselessAssignment: Useless assignment to variable - `sort`\napp/models/listing.rb:212:11: C: Style/SafeNavigation: Use safe navigation (&.) instead of checking if an object exists\napp/services/viewings/book.rb:22:3: C: Style/Documentation: Missing top-level class documentation comment\n\nsorbet:\napp/services/viewings/book.rb:66: Expected `Time` but found `T.nilable(Time)` for argument `starts_at`\napp/models/listing.rb:141: Method `price_cents` does not exist on `T.nilable(Price)`\n\n4 offenses, 2 type errors, and the two type errors look like actual nil bugs", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "clippy on the compiler, mostly noise but check the last two:\n\nwarning: this `RefCell` is borrowed twice in the same expression\n --> src/intern.rs:41:9\nwarning: large enum variant\n --> src/ast.rs:88:1\n | enum Expr { Lit(i64), Call(Box<Call>), Block([Stmt; 64]) }\nwarning: this loop could be written as a `for` loop\n --> src/lex.rs:141:5\nwarning: casting `usize` to `u32` may truncate the value\n --> src/intern.rs:52:20\nwarning: `mem::forget` on a type with a `Drop` implementation\n --> src/intern.rs:49:5\n\n34 warnings total", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "index template that got deleted, restored from a backup. does this match what the search code expects?\n\nPUT _index_template/listings\n{\n \"index_patterns\": [\"listings-*\"],\n \"template\": {\n \"mappings\": {\n \"properties\": {\n \"location\": { \"type\": \"geo_point\" },\n \"price_cents\": { \"type\": \"long\" },\n \"beds\": { \"type\": \"short\" },\n \"property_type\": { \"type\": \"keyword\" },\n \"description\": { \"type\": \"text\", \"analyzer\": \"english\" },\n \"listed_at\": { \"type\": \"date\" }\n }\n },\n \"settings\": { \"number_of_shards\": 3, \"number_of_replicas\": 1 }\n }\n}\n\nthe search code also filters on `status` and sorts on `updated_at`, neither of which appears here", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "npm audit on the mobile app before the store submission:\n\nreact-native 0.76.0 - 0.76.9\nHigh: Improper URI validation in the Linking module\nfix available via `npm audit fix --force`\nWill install [email protected], which is a breaking change\n\n@react-native-async-storage/async-storage 1.21.0 - 1.23.1\nModerate: Data written without atomic replace, corruption possible on crash\nfix available via `npm audit fix`\n\nreact-native-image-picker 7.1.0 - 7.2.2\nModerate: Activity result handling can leak the file URI to other apps\nfix available via `npm audit fix`\n\nthe async-storage one is interesting given our saved-listings bug", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "os limites de alerta do ingest, acordam-nos por nada:\n\n- alert: IngestLag\n expr: kafka_consumergroup_lag{group=\"ingest\"} > 1000\n for: 1m\n labels: { severity: page }\n\n- alert: AgentDown\n expr: up{job=\"agent\"} == 0\n for: 0m\n labels: { severity: page }\n\n- alert: EnrichErrors\n expr: rate(enrich_errors_total[5m]) > 0\n for: 1m\n labels: { severity: page }\n\ncomportamento normal: o lag passa de 1000 em todas as manhãs às 9h durante cerca de dez minutos; há sempre alguns agentes offline num universo de 40 mil hosts; e o incidente real do mês passado (uma região inteira sem eventos durante duas horas) não gerou nenhum alerta", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "pt"}
{"prompt": "diagnostic emission code is duplicated across passes with slight differences:\n\n// in type check\nsess.emit_error(format!(\"type mismatch: expected {}, found {}\", a, b), span);\n\n// in the borrow checker\nsess.diagnostic(Level::Error, \"cannot borrow as mutable\")\n .span_label(span, \"second mutable borrow\")\n .emit();\n\n// in the const folder\neprintln!(\"error: {}\", msg); // yes, really\nsess.error_count.fetch_add(1, Ordering::Relaxed);\n\n// in the plugin bridge\nDiagnostic::error(msg).with_span(span, label).emit();\n\nfour ways to report an error, one of which bypasses the diagnostic system entirely and breaks --json output", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "viewing-booking service does everything in one method and the tests need a database and a stubbed calendar:\n\nclass Viewings::Book\n def call\n raise SlotUnavailable unless available?\n viewing = Viewing.create!(listing:, agent:, starts_at:, source:)\n CalendarSync.push(agent, viewing)\n VendorMailer.viewing_booked(viewing).deliver_later\n BuyerMailer.viewing_confirmed(viewing).deliver_later\n Sms.send(buyer.phone, confirmation_text(viewing)) if buyer.phone?\n listing.touch(:last_activity_at)\n Analytics.track(\"viewing_booked\", agent_id: agent.id, listing_id: listing.id)\n AvailabilityCache.invalidate(listing)\n viewing\n end\nend\n\nsame behaviour, but the availability check and the booking need to be atomic and the rest needs to be out of the request", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "quarter planning, and this is what i have to sequence:\n\n- the double-booking bug is small in volume but every instance is a furious vendor and an angry agent\n- portal partners are complaining that our feed shows withdrawn listings for hours\n- the agent's memory growth means one large customer caps us at 200 hosts per cluster\n- the compiler's incremental correctness bug has produced two miscompiles in production code this quarter\n- a new customer needs the agent on 5.4 kernels, which we dropped support for in 2.4\n- two engineers are leaving the compiler team and one is joining in october\n- there's a store submission deadline for the mobile app in three weeks", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, thinking needed before code:\n\nOBS-410 — Agent event sampling and backpressure\nThe agent currently samples per process at a fixed rate and drops nothing until the ringbuffer fills, at which point the kernel side silently overwrites. On busy hosts this means we lose the events we most want. The proposal is adaptive sampling driven by observed volume with per-category floors, plus explicit backpressure signalling to the control plane. Concerns: sampling decisions in eBPF cost cycles per event; the control plane cannot push config faster than every 30 seconds; customers alert on event counts and adaptive sampling would make those alerts meaningless; and we have no way to tell a customer what we dropped.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "customer's security requirement for the agent, which sales has already half-agreed to:\n\n\"The agent shall not transmit file contents, command-line arguments or environment variables outside the host without explicit per-category opt-in. It shall operate in an audit-only mode in which it collects and displays locally but transmits nothing. The customer shall be able to review the exact schema of transmitted data. A failure of the agent shall not affect the host: no kernel panic, no CPU starvation, no disk exhaustion. Evidence of the last requirement shall include the results of fault injection testing.\"\n\nwe transmit command lines by default, have no local-only mode, no published schema, and have never done fault injection. i want the plan and an honest view of what we can claim by the deadline", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the agent fleet screen in our console, which platform engineers live in:\n\nFleet view\n- Table of hosts: hostname, agent version, kernel, last seen, events/sec, degraded reason. Virtualised to 40,000 rows.\n- Degraded hosts sort first by default; \"degraded\" needs a plain-language reason, not an error code.\n- Filters: version, kernel, tenant, degraded state; filters are in the URL so they can be shared in an incident.\n- Bulk actions: restart agent, change sample rate, collect diagnostics. Each shows how many hosts it will affect before confirming.\n- A version rollout view: percentage on each version over time, with the ability to pause a rollout.\n- Host detail: loaded programs with their status, map utilisation, recent config changes, and the last ten errors.\n- Everything must remain usable when the control plane is degraded — show stale data with its age rather than a spinner.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings on the listing detail page, from an audit a portal partner ran:\n\n1. The photo carousel is operable only by swipe; there are no next/previous controls and arrow keys do nothing.\n2. Photo alt text is the filename (\"IMG_4471.HEIC\") for every image.\n3. The floorplan opens in a lightbox that traps focus and has no close button reachable by keyboard.\n4. Price change history is conveyed by red and green arrows with no text.\n5. The \"book a viewing\" form's date picker is a custom control with no role and no keyboard support.\n6. Headings jump from h1 to h4 in the description section.\n7. The map embed has no accessible name and is included in the tab order with nothing to do.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the listing pages actually use:\n\ntokens:\n color.text.primary #101418 / #F2F5F7\n color.text.muted #5B6570 / #9AA6B2\n color.brand #0B6E4F\n color.price.up #B42318\n color.price.down #067647\n space 4/8/12/16/24/32/48, radius 6/10/16, shadow.sm/md/lg\n type: display 28/34, title 20/26, body 15/22, caption 13/18\n\nthe listing pages: nine hardcoded colours, three of which are the brand green at slightly different values; paddings of 5, 11, 13 and 22; two type sizes not in the scale; price direction shown only by colour; and a shadow defined inline in four components\n\nbring it onto the tokens and give price direction a non-colour indicator while you're in there", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for agent config versioning, needs implementing in the control plane:\n\nCREATE TABLE agent_configs (\n id uuid PRIMARY KEY,\n tenant_id uuid NOT NULL,\n scope text NOT NULL CHECK (scope IN ('tenant','group','host')),\n scope_id text,\n body jsonb NOT NULL,\n version int NOT NULL,\n created_by text NOT NULL,\n created_at timestamptz NOT NULL DEFAULT now(),\n UNIQUE (tenant_id, scope, scope_id, version)\n);\n\nagents poll every 30 seconds with their current version; the effective config is host over group over tenant; a rollout can be paused, which means agents keep their current version rather than reverting; and an agent that receives a config it can't apply must report why and keep running on the previous one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "sample_rate should be per host", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "async-storage bump before submission", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "cache cargo registry in CI", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "thumbnails need rotate() for EXIF", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "el filtro de precio no acepta decimales", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "es"}
{"prompt": "cap the search page size at 100", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "add `status` to the index template", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "process_tree off by default", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "IngestLag needs a 15 minute window", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "Release-Tests im CI weglassen", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
{"prompt": "unique index on (listing_id, slot)", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "the compiler's error output needs colour that survives being piped into a file", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "agent config is parsed in three places with different defaults for the same keys", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "our internal wiki page on the photo pipeline describes two lambdas and there are three, one of which advances the listing state and is therefore the one everyone needs to understand during an incident. write the page properly, covering each stage, what failure looks like, and which state transitions are irreversible tell me if any of that is a bad idea before doing it.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "pins should show price in thousands", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "\"search this area\" button on the map", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "degraded hosts should sort first", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "filters belong in the URL", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "photo alt text is the filename", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "間取り図のライトボックスが閉じられません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
{"prompt": "carousel has no keyboard controls", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "bottom sheet snaps to the wrong detent", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "stale fleet data looks live", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "pull the emails out of Viewings::Book", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "un seul modèle de récupération de données", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "fr"}
{"prompt": "`price_cents` naming, everywhere", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "extract the bbox parsing helper", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "inline `slots_between`, one caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "one diagnostic emission path", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "doc comments on the plugin diagnostic API", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "changelog for agent 2.5", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota para os parceiros sobre o feed", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "pt"}
{"prompt": "document what sample_rate really means", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the sampling proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the fingerprint fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "¿por qué el feed muestra anuncios retirados?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "es"}
{"prompt": "can two agents book the same slot?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through the photo pipeline", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "geo search fails in one region", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "favourites disappear after relaunch", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "warum belegt der Agent 2 GB RAM?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a host's loaded programs", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "press on", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "leaner", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "you know the priorities", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo del compilador, sigue", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "es"}
{"prompt": "clean as you go", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "same again", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "partner doc", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "anything small", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "cast an eye over it", "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": "more of that", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "mobile app's offline story is three different patterns and a hope, and the saved-listings bug is just the visible part. i want a position on what offline should mean for this app — which surfaces work, what happens to writes, how conflicts resolve — before anyone touches the storage layer again the store submission is in three weeks, so anything shipped now has to be small.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "compiler's diagnostics are inconsistent in seven visible ways and plugin authors are copying whichever example they found first. write the error message style guide — wording, capitalisation, when a code is required, how spans and notes are used, when to suggest a fix — with our current worst examples rewritten as illustrations the guide should be enforceable by a lint, so wording rules need to be mechanical where possible.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "customers deploy the agent across whole fleets from a sample config file with no documentation, which is how one of them ran unsampled for a month. write the configuration reference covering what each option really does, the ones that interact badly, and the three that mean something different from what their names suggest assume the reader is a platform engineer rolling this to forty thousand hosts.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "public listings API is documented by a README from 2024 and the thing partners get wrong every time is that a price change doesn't move updated_at. write the reference properly, with the caching implications spelled out, and a worked example of a partner keeping a mirror in sync three partners integrate against it today and a fourth starts next month.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "string interner leaks every string deliberately and transmutes a borrow to 'static, which is fine for a one-shot compiler and possibly catastrophic in a long-lived language server. work through whether the sessions really are isolated, what happens when one is dropped, and whether the language server can end up with a dangling symbol the language server runs for days in an editor, which is where this would show up.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "eBPF program updates a hash map on every connection and relies on a userspace sweep every thirty seconds to remove entries, which on a busy host cannot possibly keep up. read the program and the sweep together and tell me what happens once the map is full — silently dropped updates, or something worse on our busiest customer host that's about twelve thousand events a second.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "pass manager is a wall of conditionals including a second const-fold pass nobody can explain, and removing it changes generated code. restructure it into an explicit ordered pipeline with each pass declaring its own preconditions, and keep the emitted binary identical for our benchmark suite before we discuss removing anything our benchmark suite is the only thing standing between us and silently changing generated code.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "two agents booked the same viewing slot seventeen milliseconds apart and our availability check is a select followed by an insert with no constraint behind it. work out how often this has happened historically before we add the index, because the vendor-facing consequences of the ones we've already sent are the actual problem vendors get an email per booking, so the ones already sent are what we actually have to handle.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "map screen is our most-used surface and it currently refetches on every pan, drops frames with three hundred pins, and has no offline behaviour at all. build it to the new spec, keeping the sheet's three detents and making sure the accessible path through the list actually works the target device is a mid-range android from 2021, which is what most of our users have.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "before we change sampling i want the design written down — adaptive rates, per-category floors, what we tell customers about what we dropped — and then the drop accounting implemented, because we currently can't answer that question at all that's the whole of it, but shout if the context is thin.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "incremental correctness bug needs a proper fix and a regression test that would have caught it. design the fingerprint change with me first, including the cache invalidation on upgrade, then implement it we've been burned by guessing at this before, so evidence over instinct please.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "portal feed should probably be event-driven rather than diffing on updated_at, but that's a bigger change than this quarter allows. give me the target design, then implement the price-change events so partners at least stop showing stale prices i'd rather have the reasoning than a quick answer here. there's no rush on this week specifically, but it keeps costing us time.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "unsere Offline-Strategie in der App ist dreimal unterschiedlich gebaut und verliert dabei Favoriten. Ich hätte gern zuerst ein Konzept, was offline überhaupt funktionieren soll, und danach die Umsetzung für die gespeicherten Anzeigen", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "de"}
{"prompt": "supporting 5.4 kernels again needs a decision and, if we say yes, a compatibility path that doesn't fork the codebase. work through the options, then prototype whichever one you'd recommend against a 5.4 test host happy to be told this is the wrong shape entirely. nobody has trusted this code for about a year, which is part of the problem.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "agent's configuration reference needs writing and i suspect at least two options don't do what their names say. produce the reference, and give me the list of options whose behaviour we should change rather than document i've already spent an afternoon on it and got nowhere useful.", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "listings API reference has to exist before the fourth partner integrates, and while writing it please confirm whether withdrawn listings really do vanish from the feed rather than appearing as deleted", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la guía de despliegue del agente para clientes que lo instalan en toda su flota, y comprueba en el código si el límite de CPU se aplica de verdad o solo es orientativo", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "ingest runbook should be a page rather than a slack thread, and the ingest tier restart that drops every connected agent's ringbuffer deserves a guard. write the runbook, then add the confirmation if the answer is that it's fine as it is, that's a useful answer too.", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "compiler reports errors four different ways, one of which bypasses the diagnostic system and breaks JSON output entirely. unify them, and tell me which existing tools would break if the JSON output suddenly contained diagnostics it never saw before it doesn't have to be elegant, it has to be defensible in a review.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "react native screens fetch data three different ways with three error behaviours. bring them onto one pattern, and write the short note for the team explaining which one and why, because this is the third time we've had this conversation it's been like this long enough that nobody trusts it any more. the last person who touched this left, so there's nobody to ask.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "photos come out rotated from iOS uploads and i think the thumbnail worker drops EXIF orientation. confirm it, then fix the pipeline and tell me how many existing thumbnails need regenerating", "purpose": "debugging", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "fleet view needs a rollout pause control, and we should agree what pausing means for agents mid-download before it exists. decide that with me, then build it", "purpose": "frontendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "CI duplicates the debug test run in release mode and rebuilds the compiler for the UI tests. cut it down, and tell me what coverage we lose by doing so", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "config versioning for agents needs the effective-config resolution agreed before it's built — host over group over tenant, and what a paused rollout means. settle that, then implement", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "percolator index is rebuilt nightly from saved searches, so an edit doesn't take effect until the next day", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "rails app has three ways to express money and the mobile API returns two of them in the same payload", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "lexer and the language server's lexer are separate implementations that have drifted on string escapes", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "rename `Listing#status` to something that admits it's a state machine with six values and two of them unused", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain how a listing gets into \"processing\" and what takes it out again", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "why does the fleet query run per tenant every thirty seconds rather than once for everyone", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "someone should check whether our search endpoint can be made to scan every shard by a crafted filter", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that the thumbnail worker strips all metadata including copyright", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment le cache de disponibilité est invalidé après une réservation ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/search.md describes the geo filter as optional, which stopped being true two versions ago", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "a short note on why we're moving to an LRU map in the agent, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "rustdoc on our plugin API promises span validation that doesn't exist", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer note about dropping 5.4 kernel support, for the two customers still on it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "listing URL includes the address, so a withdrawn listing is still findable by search engines", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "staging hosts run five containers and prod runs four hundred, with identical map sizes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "floorplan detector fires on any listing whose address contains the word plan", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "how should we version the agent's wire protocol now that fleets run three versions at once", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test a compiler optimisation pass when the failure mode is a wrong program", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether saved searches should be percolated or evaluated on write", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "three partners want real-time listing updates rather than a fifteen-minute feed, what's our story", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "we need a plan for running the agent on hosts where we can't load eBPF at all", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to a tenant's events when they exceed their contracted volume mid-month", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint returning a listing's price history with the source of each change, for the detail page", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "delta feed needs a sequence number that survives a redeploy and a gap-recovery path", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "agents should buffer to disk with a size cap when ingest is unreachable, rather than dropping silently", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "viewing availability should be computed from a single source rather than three set operations at request time", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "host detail screen needs a map utilisation chart so we can see which map fills first", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "whatever gets us through the submission", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "next bit of the feed work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "i'd like an honest read of whether our language server can end up holding a symbol from a dropped compilation session, given the interner leaks and transmutes, and if it can, the fix — ideally one that doesn't require rewriting every pass that holds a Symbol the sooner we know the size of it, the better.", "purpose": "review", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "the lexer exists twice, once in the compiler and once in the language server, and they have drifted on string escapes badly enough that the editor highlights code the compiler rejects. merge them onto one implementation, and tell me which existing editor behaviours change as a result i've spent an afternoon on it already and got nowhere useful.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "agent configuration is parsed in three places with different defaults for the same keys, which is why a documented default is sometimes not the effective one. consolidate the parsing, then write down the resulting defaults so the reference we publish is generated rather than hand-maintained this has come up in three separate reviews now. the sooner we know roughly how big this is, the better for planning.", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "saved searches are percolated against an index rebuilt nightly, so an edit doesn't take effect for a day and users assume it's broken. decide with me whether to percolate live or evaluate on write, then implement whichever we land on for new saved searches first it doesn't have to be perfect, it has to be defensible.", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "our listing URLs embed the address, so a withdrawn property remains findable through search engines and vendors have complained about it twice this month. change the URL scheme for new listings, keep the old ones resolving with a redirect, and make sure withdrawn listings return the right status code rather than a soft 404 page that's the whole of it, but shout if the context is thin.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt":"Gateway: Ticket OPS-50147: retire the legacy replay path for JunctionAmberFilterFlow\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 JunctionAmberFilterFlow 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":"Test Suite 'JunctionEchoRegistryFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[JunctionEchoRegistryFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/junction/config/staging.toml:144: error: -[JunctionEchoRegistryFlowTests 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 '-[JunctionEchoRegistryFlowTests 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\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Bring JunctionEchoRegistryFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Renderer: # projects/junction/ml/pipeline/features.py\n[worker.junctionsummitproxyflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctionsummitproxyflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctionsummitproxyflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionSummitProxyFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50143\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/junction/ml/pipeline/features.py. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Make JunctionOpalRouterStore keyboard navigable","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'JunctionCopperBridgeFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[JunctionCopperBridgeFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/junction/cmd/exporter/main.py:144: error: -[JunctionCopperBridgeFlowTests 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 '-[JunctionCopperBridgeFlowTests 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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Bring JunctionCopperBridgeFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"JunctionDriftConsoleCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"# CI job 50144: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Cloudflare Workers\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] JunctionMosaicGridFlowIntegration.replays_after_timeout ... ok\n[test] JunctionMosaicGridFlowIntegration.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\nDeliver the JunctionMosaicGridFlow 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":"Collapse the JunctionFlintTimelineService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"JunctionMosaicGridCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/junction/web/components/FilterDrawer.vue b/projects/junction/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/web/components/FilterDrawer.vue\n+++ b/projects/junction/web/components/FilterDrawer.vue\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Consolidate JunctionPrismCacheFlow'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":"Summarize the JunctionTideWorkerService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Support wants the behavior in projects/junction/services/ledger/replay.go recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"JunctionOrbitSyncCoordinator: sort out the rough edge","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Outline a safer JunctionOpalRouterService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-50120\n\n08:02 deploy JunctionOspreyJobFlow 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 JunctionOspreyJobFlow 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":"projects/junction/workers/thumbnail/consumer.ex 里的 JunctionEmberRelayService 最近在 Spring Boot 流程中出现间歇性问题。 请追踪 queue、scheduler 和取消路径，对比假设，先定位原因再提修改。\n\n约束：\n- 继续使用 Spring Boot\n- 保持兼容性和取消语义\n- 改动只限于 JunctionEmberRelayService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Our support and SDK teams keep answering the same questions about JunctionHarborIndexService, but the current prose in projects/junction/crates/index/src/segment.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- retain the existing CLI flags and exit codes\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to JunctionHarborIndexService and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Em projects/junction/ui/settings/PrivacyPane.tsx, o JunctionEmberRelayStore tem um problema intermitente no fluxo de Spring Boot. Finalize o layout responsivo, estados vazio e retry, foco por teclado, dark mode e reduced motion.\n\nRestrições:\n- continuar com Spring Boot\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao JunctionEmberRelayStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"pt"}
{"prompt":"Indexer: # projects/junction/workers/thumbnail/consumer.ex\n[worker.junctionslateeditorcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctionslateeditorcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctionslateeditorcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionSlateEditorCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50155\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/junction/workers/thumbnail/consumer.ex. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/junction/Sources/CLI/Commands/Doctor.swift b/projects/junction/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/junction/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\nRead the artifact above as a skeptical reviewer. Is JunctionDriftConsoleFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Apparently: A copied hex color in JunctionAtlasSearchStore lost one digit. Replace #1F293 with the approved #1F2937 and keep the rest of the stylesheet untouched.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"The JunctionMosaicGridService 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":"Lately: projects/junction/cmd/exporter/main.py 里的 JunctionSummitProxyStore 最近在 Kotlin coroutines 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 Kotlin coroutines\n- 保持兼容性和取消语义\n- 改动只限于 JunctionSummitProxyStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"zh"}
{"prompt":"JunctionTideWorkerCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-50125: retire the legacy replay path for JunctionMoonlitSDKFlow\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 JunctionMoonlitSDKFlow decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"JunctionJuniperCLIFlow's staging timeout is already known to be wrong: change the single projects/junction/Sources/App/SessionStore.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":"Centre la modale JunctionNovaPickerService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"fr"}
{"prompt":"Oddly: Test Suite 'JunctionVelaDrawerFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[JunctionVelaDrawerFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/junction/web/components/FilterDrawer.vue:144: error: -[JunctionVelaDrawerFlowTests 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 '-[JunctionVelaDrawerFlowTests 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\nFinish the visible JunctionVelaDrawerFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Fresh release brief for JunctionRainfallDBCoordinator:\n- primary outcome: change JunctionRainfallDBCoordinator'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/junction/web/components/FilterDrawer.vue\n- platform constraint: GraphQL\n- known complication: memory growth during hour-long imports\n\nBoth results are required, but they should remain independently reviewable. Retain the existing cli flags and exit codes; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Sequence JunctionGarnetModalService's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"JunctionVelaDrawerCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Currently: The JunctionEchoRegistryService surface in projects/junction/config/staging.toml 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":"Production says JunctionCopperBridgeService is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. Reconstruct the failing timeline from logs and tests, identify which invariant first breaks, and distinguish causal signals from effects or cleanup noise.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- retain the existing CLI flags and exit codes\n- retain the current Kotlin coroutines operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Please turn JunctionAmberFilterService's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"JunctionAmberFilterCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"JunctionKiteSchedulerCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"JunctionFrostPanelStore's staging timeout is already known to be wrong: change the single projects/junction/src/sync/reconcile.ts value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Check JunctionMoonlitSDKService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-50154\n\n08:02 deploy JunctionFrostPanelCoordinator 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 JunctionFrostPanelCoordinator 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":"Ist JunctionNovaPickerStore sicher?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"de"}
{"prompt":"Today: The behavior of JunctionWrenExportService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/junction/web/components/FilterDrawer.vue. 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- retain the existing CLI flags and exit codes\n- retain the current GraphQL operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter JunctionGarnetModalFlow\n RUN v3.2.4 /workspace/apps/console\n × JunctionGarnetModalFlow > 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=50124 phase=resume storedCursor=seg-0183\n session=50124 phase=fetch requestCursor=seg-0183 pageSize=200\n session=50124 phase=commit receivedCursor=seg-0184 itemCount=0\n session=50124 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the JunctionGarnetModalFlow 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":"# projects/junction/Sources/CLI/Commands/Doctor.swift\n[worker.junctionjuniperclicoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctionjuniperclicoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctionjuniperclicoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionJuniperCLICoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50158\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/junction/Sources/CLI/Commands/Doctor.swift. 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":"Ticket OPS-50129: retire the legacy replay path for JunctionMicaProfileFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Turn the material above into a concise JunctionMicaProfileFlow 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":"Read projects/junction/db/migrations/20260730_events.sql and tell me whether JunctionBasilRunnerStore can acknowledge work before its durable write completes; this is a read-only safety pass.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"JunctionOpalRouterCoordinator: ship, then document","purpose":"backendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"UI ticket DES-50146: finish the compact JunctionIrisBatchFlow filter experience\n\nRoute: /catalog/search\nSource: projects/junction/internal/auth/refresh.go\nFramework: GraphQL\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nBring JunctionIrisBatchFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Context: diff --git a/projects/junction/services/ledger/replay.go b/projects/junction/services/ledger/replay.go\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/services/ledger/replay.go\n+++ b/projects/junction/services/ledger/replay.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\nSplit JunctionLumenChartFlow 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":"JunctionMarbleTokenCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Describe JunctionOspreyJobStore's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The behavior of JunctionTideWorkerStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/junction/packages/api/openapi.yaml. 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- retain the existing CLI flags and exit codes\n- retain the current Kafka operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL 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":"Stream JunctionSableParserService's audit events","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"JunctionEmberRelayCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Is there a cleaner way to separate JunctionBeaconStoreService's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"JunctionBirchMigratorCoordinator needs a paired pass: assess ownership and failure handling in projects/junction/pkg/cache/lease.rs, plus capture the contract and rollback note for consumers. Use projects/junction/pkg/cache/lease.rs as the source of truth, preserve the Kafka contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Dedupe JunctionFlintTimelineStore's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"JunctionRavenSessionService é seguro?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"pt"}
{"prompt":"JunctionEchoRegistryCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'JunctionMapleQueueFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[JunctionMapleQueueFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/junction/app/src/main/SyncWorker.kt:144: error: -[JunctionMapleQueueFlowTests 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 '-[JunctionMapleQueueFlowTests 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 JunctionMapleQueueFlow'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":"$ pnpm test --filter JunctionTideWorkerFlow\n RUN v3.2.4 /workspace/apps/console\n × JunctionTideWorkerFlow > 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=50117 phase=resume storedCursor=seg-0183\n session=50117 phase=fetch requestCursor=seg-0183 pageSize=200\n session=50117 phase=commit receivedCursor=seg-0184 itemCount=0\n session=50117 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\nDetermine why JunctionTideWorkerFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Background: Incident timeline — INC-50114\n\n08:02 deploy JunctionAsterWebhookFlow 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 JunctionAsterWebhookFlow 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":"Question: Ticket OPS-50159: retire the legacy replay path for JunctionPineMetricsCoordinator\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 JunctionPineMetricsCoordinator 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":"Observation: projects/junction/ml/pipeline/features.py の JunctionSummitProxyService で、Kotlin coroutines の flow に断続的な問題が起きています。 consumer 向けに contract、error、retry、コピー可能な例を含む文書を書き、handler は変更しないでください。\n\n制約:\n- Kotlin coroutines を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は JunctionSummitProxyService のみ","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"ja"}
{"prompt":"Move JunctionEchoRegistryStore's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Two asks around JunctionMoonlitSDKCoordinator: (1) finish JunctionMoonlitSDKCoordinator's responsive empty and retry states; (2) correct the known stale timeout beside it. Retain the existing cli flags and exit codes, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Fresh release brief for JunctionAsterWebhookCoordinator:\n- primary outcome: separate JunctionAsterWebhookCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/junction/db/migrations/20260730_events.sql\n- platform constraint: Cloudflare Workers\n- known complication: cancellation being swallowed at the repository boundary\n\nBoth results are required, but they should remain independently reviewable. Retain the existing cli flags and exit codes; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Check JunctionLumenChartStore's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Unifie les validateurs de JunctionRavenSessionStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"fr"}
{"prompt":"Ownership of JunctionFrostPanelService 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- retain the existing CLI flags and exit codes\n- retain the current Cloudflare Workers operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"What does JunctionBirchMigratorStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Milestones for replacing JunctionMicaProfileService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up JunctionCedarPolicyCoordinator. First, separate JunctionCedarPolicyCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/junction/engine/render/atlas.cpp, which follows Spring Boot conventions and currently suffers from two validators with subtly different error strings. Retain the existing cli flags and exit codes.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"JunctionSummitProxyCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"JunctionFernSnapshotFlow 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.6,"slice":"core","lang":"en"}
{"prompt":"Release verification found a single stale JunctionCedarPolicyService value; the cause, desired value, and affected assertion are already agreed. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- retain the existing CLI flags and exit codes\n- retain the current Spring Boot operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The JunctionQuartzPlayerFlow surface in projects/junction/ml/pipeline/features.py is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Constraint: Two deliverables are holding up JunctionCopperBridgeCoordinator. First, separate JunctionCopperBridgeCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/junction/ml/pipeline/features.py, which follows Kotlin coroutines conventions and currently suffers from stale cursors when a page is resumed. Retain the existing cli flags and exit codes.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"JunctionDeltaCanvasStore crashes after reconnect","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"JunctionDeltaCanvasCoordinator: sequence, then ship","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Decouple JunctionMoonlitSDKStore's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a deadlock that appears only during shutdown in JunctionDriftConsoleService, 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":"Ticket OPS-50151: retire the legacy replay path for JunctionWrenExportCoordinator\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 JunctionWrenExportCoordinator, 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":"Request: Two asks around JunctionLumenChartCoordinator: (1) change JunctionLumenChartCoordinator's known staging timeout from 15 to 30 seconds; (2) give the existing implementation a read-only safety pass. Retain the existing cli flags and exit codes, and leave a clear boundary between the resulting artifacts or edits.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"PM needs a concise migration note for JunctionIrisBatchStore, 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":"Is there a cleaner way to separate JunctionPineMetricsFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"JunctionHarborIndexCoordinator is blocking the next release because a misleading timeout name used in five packages. I need two concrete outcomes from a single pass: assess ownership and failure handling in projects/junction/pkg/cache/lease.rs, and capture the contract and rollback note for consumers. Use the existing Kafka conventions in projects/junction/pkg/cache/lease.rs; retain the existing CLI flags and exit codes. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Goal: The data is already available in projects/junction/engine/render/atlas.cpp; 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":"Symptom: The public surface of JunctionJuniperCLIService is frozen, but its internal ownership in projects/junction/Sources/App/SessionStore.swift 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 JunctionJuniperCLIService\n- retain the existing CLI flags and exit codes\n\nThe relevant code crosses logistics, WebAssembly, MySQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"JunctionWillowCodecCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Memory attributed to JunctionKiteSchedulerService 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":"For JunctionRavenSessionCoordinator, finish JunctionRavenSessionCoordinator's responsive empty and retry states; once that is complete, capture the contract and rollback note for consumers. Work from projects/junction/config/staging.toml, stay with Kafka, and retain the existing CLI flags and exit codes. Keep the two outcomes separately reviewable.","purpose":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"JunctionMicaProfileCoordinator needs a paired pass: change JunctionMicaProfileCoordinator's known staging timeout from 15 to 30 seconds, plus capture the contract and rollback note for consumers. Use projects/junction/app/src/main/SyncWorker.kt as the source of truth, preserve the Cloudflare Workers contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.3,"slice":"mixed","lang":"en"}
{"prompt":"Give JunctionLedgerGateStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"JunctionCloudReconcilerCoordinator is blocking the next release because a feature flag whose default differs between environments. I need two concrete outcomes from a single pass: find the unknown cause of a feature flag whose default differs between environments, and capture the contract and rollback note for consumers. Use the existing Spring Boot conventions in projects/junction/ui/settings/PrivacyPane.tsx; retain the existing CLI flags and exit codes. 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":"debugging","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Introduce a durable deduplication key for JunctionFernSnapshotStore events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"JunctionOspreyJobCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"# projects/junction/Sources/App/SessionStore.swift\n[worker.junctionorbitsyncflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctionorbitsyncflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctionorbitsyncflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionOrbitSyncFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50148\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 JunctionOrbitSyncFlow's staging timeout with the shown production value and refresh only the focused config test; nothing else in the paste should move.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"En projects/junction/web/components/FilterDrawer.vue, JunctionRainfallDBStore tiene un problema intermitente en el flujo de GraphQL. Lee el flujo actual y dime si ownership, cancelación y orden son seguros; solo necesito el análisis.\n\nRestricciones:\n- seguir con GraphQL\n- conservar compatibilidad y cancelación\n- limitar el cambio a JunctionRainfallDBStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"es"}
{"prompt":"Why is JunctionDeltaCanvasService stalling?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a misleading timeout name used in five packages in JunctionCoralUploadStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Headsup: Two asks around JunctionFlintTimelineCoordinator: (1) lay out a staged migration for JunctionFlintTimelineCoordinator; (2) also add the visible loading and offline states. Retain the existing cli flags and exit codes, 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":"Ticket OPS-50157: retire the legacy replay path for JunctionLedgerGateCoordinator\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 JunctionLedgerGateCoordinator, 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":"Since the last release, JunctionCraneWorkspaceStore has shown a misleading timeout name used in five packages; 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- retain the existing CLI flags and exit codes\n- stay compatible with the existing GraphQL deployment\n- keep the work scoped to JunctionCraneWorkspaceStore and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Trace JunctionBirchMigratorService's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"JunctionAtlasSearchCoordinator: make the api less awkward","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"JunctionAcornWidgetStore has four wrappers that only translate the same error enum. Collapse them into one adapter and preserve every public case, message, and metric label.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"# projects/junction/crates/index/src/segment.rs\n[worker.junctionharborindexflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctionharborindexflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctionharborindexflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionHarborIndexFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50112\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 JunctionHarborIndexFlow'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":"FYI: projects/junction/engine/render/atlas.cpp has grown through several launches, and JunctionCoralUploadService 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- retain the existing CLI flags and exit codes\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to JunctionCoralUploadService and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Meanwhile: # projects/junction/lib/codec/frame.cc\n[worker.junctioncinderauthflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctioncinderauthflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctioncinderauthflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionCinderAuthFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50130\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 JunctionCinderAuthFlow'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":"How does JunctionVelaDrawerStore propagate cancellation through the GraphQL boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"JunctionBasilRunnerCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"JunctionSableParserCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"A flaky failure around JunctionCloudReconcilerStore 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 JunctionCloudReconcilerStore\n- retain the existing CLI flags and exit codes\n\nThe relevant code crosses logistics, WebAssembly, MySQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Drop JunctionSpruceDaemonService's unused import","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"JunctionNimbusFormCoordinator needs a paired pass: change JunctionNimbusFormCoordinator's known staging timeout from 15 to 30 seconds, plus capture the contract and rollback note for consumers. Use projects/junction/infra/modules/edge/main.tf as the source of truth, preserve the GraphQL contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Architect a gradual ownership transfer for JunctionBeaconStoreStore across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Unify the JunctionCloudReconcilerService validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Locally: Ticket OPS-50127: retire the legacy replay path for JunctionRavenSessionFlow\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 JunctionRavenSessionFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"Compare the old and new JunctionMapleQueueStore 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":"For JunctionCinderAuthCoordinator, change JunctionCinderAuthCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, capture the contract and rollback note for consumers. Work from projects/junction/engine/render/atlas.cpp, stay with Spring Boot, and retain the existing CLI flags and exit codes. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"The public surface of JunctionSlateEditorService is frozen, but its internal ownership in projects/junction/ui/settings/PrivacyPane.tsx 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 JunctionSlateEditorService\n- retain the existing CLI flags and exit codes\n\nThe relevant code crosses logistics, WebAssembly, MySQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"What does JunctionGarnetModalStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"JunctionMarbleTokenService needs an idempotent replay endpoint backed by Kafka; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"PM is preparing the JunctionHarborIndexStore 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 JunctionHarborIndexStore\n- retain the existing CLI flags and exit codes\n\nThe relevant code crosses logistics, WebAssembly, MySQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Sketch the JunctionMicaProfileStore migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"The JunctionOrbitSyncStore 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":"Production: projects/junction/web/components/FilterDrawer.vue の JunctionWrenExportFlow で、GraphQL の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- GraphQL を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は JunctionWrenExportFlow のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"ja"}
{"prompt":"Staging: The destination for JunctionAcornWidgetService is broadly agreed; the missing piece is a reversible route from projects/junction/pkg/cache/lease.rs to that target. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside JunctionAcornWidgetService\n- retain the existing CLI flags and exit codes\n\nThe relevant code crosses logistics, WebAssembly, MySQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"JunctionAcornWidgetFlow's staging timeout is already known to be wrong: change the single projects/junction/pkg/cache/lease.rs value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"CI: For JunctionGarnetModalCoordinator, assess ownership and failure handling in projects/junction/src/sync/reconcile.ts; once that is complete, capture the contract and rollback note for consumers. Work from projects/junction/src/sync/reconcile.ts, stay with Cloudflare Workers, and retain the existing CLI flags and exit codes. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Incident timeline — INC-50150\n\n08:02 deploy JunctionCoralUploadCoordinator 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 JunctionCoralUploadCoordinator release note and operator runbook section. State impact, detection, rollback, and the client-visible contract; do not modify code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/junction/cmd/exporter/main.py b/projects/junction/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/cmd/exporter/main.py\n+++ b/projects/junction/cmd/exporter/main.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Restructure JunctionQuartzPlayerCoordinator 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":"JunctionNovaPickerCoordinator: polish, then correct","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/junction/workers/thumbnail/consumer.ex b/projects/junction/workers/thumbnail/consumer.ex\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/workers/thumbnail/consumer.ex\n+++ b/projects/junction/workers/thumbnail/consumer.ex\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is JunctionEmberRelayFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-50111: retire the legacy replay path for JunctionRainfallDBFlow\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 JunctionRainfallDBFlow 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":"Give JunctionNimbusFormStore a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Atlas: For JunctionSpruceDaemonCoordinator, separate JunctionSpruceDaemonCoordinator's policy from transport without behavior changes; once that is complete, correct the known stale timeout beside it. Work from projects/junction/ml/pipeline/features.py, stay with Kotlin coroutines, and retain the existing CLI flags and exit codes. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"En projects/junction/ml/pipeline/features.py, JunctionQuartzPlayerService tiene un problema intermitente en el flujo de Kotlin coroutines. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con Kotlin coroutines\n- conservar compatibilidad y cancelación\n- limitar el cambio a JunctionQuartzPlayerService Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con Kotlin coroutines alrededor de JunctionQuartzPlayerService.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"es"}
{"prompt":"# CI job 50122: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Kafka\n\n[setup] restoring cache key deps-a2f91c ... hit\n[setup] starting postgres:17 ... healthy after 4.2s\n[setup] starting redis:8 ... healthy after 0.8s\n[test] shard 3/8 selected 412 tests\n[test] JunctionSableParserFlowIntegration.replays_after_timeout ... ok\n[test] JunctionSableParserFlowIntegration.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\nFind the source of this JunctionSableParserFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Split projects/junction/web/components/FilterDrawer.vue by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Does JunctionSpruceDaemonStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Dedupe JunctionAsterWebhookService's cursor conversion","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Unify the JunctionPrismCacheStore validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Beacon: The next client release depends on a new JunctionFernSnapshotService capability in projects/junction/internal/auth/refresh.go, with GraphQL already chosen by the platform group. Implement the endpoint and durable cursor, enforce tenant authorization and idempotency, emit useful spans, cap work per request, and include focused tests for retries, cancellation, and malformed cursors.\n\nConstraints:\n- retain the existing CLI flags and exit codes\n- stay compatible with the existing GraphQL deployment\n- keep the work scoped to JunctionFernSnapshotService and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"JunctionPrismCacheCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/junction/app/src/main/SyncWorker.kt: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: junctionnovapickerflow::scheduler::LeaseTask::flush\n at ./projects/junction/app/src/main/SyncWorker.kt:217:18\n 4: junctionnovapickerflow::scheduler::LeaseTask::shutdown\n at ./src/scheduler/lease.rs:301:14\n 5: tokio::runtime::task::core::Core::poll\n 6: tokio::runtime::scheduler::multi_thread::worker::Context::run_task\n 7: tokio::runtime::context::runtime::enter_runtime\n\nnote: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.\nruntime metrics: active_tasks=3 queued_tasks=0 open_channels=0 shutdown_reason=SIGTERM grace_ms=10000\nThe panic is only visible during rolling deploys. Requests have already drained, the sender is intentionally dropped by the coordinator, and the process exits successfully despite the panic hook writing this trace.\n\nFind the source of this JunctionNovaPickerFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Cinder: Unify the JunctionLumenChartService validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Correct the JunctionCraneWorkspaceService flag default","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Introduce a durable deduplication key for JunctionWillowCodecStore events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"projects/junction/ml/pipeline/features.py has grown through several launches, and JunctionCopperBridgeStore 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- retain the existing CLI flags and exit codes\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to JunctionCopperBridgeStore and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.\n\nThe target structure is settled; carry out the behavior-preserving edits rather than writing another strategy.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'JunctionAtlasSearchFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[JunctionAtlasSearchFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/junction/ui/settings/PrivacyPane.tsx:144: error: -[JunctionAtlasSearchFlowTests 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 '-[JunctionAtlasSearchFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Use the UI evidence to complete JunctionAtlasSearchFlow'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":"Please resist widening this one: JunctionPineMetricsStore works, but staging still carries a setting that production corrected last month. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside JunctionPineMetricsStore\n- retain the existing CLI flags and exit codes\n\nThe relevant code crosses logistics, WebAssembly, MySQL. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"On compact widths, JunctionKiteSchedulerStore'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":"JunctionSlateEditorFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/junction/ui/settings/PrivacyPane.tsx and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"How does JunctionAmberFilterStore propagate cancellation through the Kafka boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Compare JunctionCinderAuthService's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Animate the JunctionNimbusFormService drawer","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-50116\n\n08:02 deploy JunctionCraneWorkspaceFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current JunctionCraneWorkspaceFlow 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":"UI ticket DES-50142: finish the compact JunctionMarbleTokenFlow filter experience\n\nRoute: /catalog/search\nSource: projects/junction/pkg/cache/lease.rs\nFramework: Kafka\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 JunctionMarbleTokenFlow'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":"Delta: diff --git a/projects/junction/infra/modules/edge/main.tf b/projects/junction/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/infra/modules/edge/main.tf\n+++ b/projects/junction/infra/modules/edge/main.tf\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is JunctionFernSnapshotCoordinator's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"// projects/junction/crates/index/src/segment.rs\nfinal class JunctionAcornWidgetCoordinatorCoordinator {\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 JunctionAcornWidgetCoordinator; 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":"Before touching projects/junction/internal/auth/refresh.go, 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":"JunctionBeaconStoreCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"This should remain a deliberately small patch: JunctionCedarPolicyStore has one known configuration mistake in projects/junction/engine/render/atlas.cpp, 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- retain the existing CLI flags and exit codes\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to JunctionCedarPolicyStore and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Security flagged JunctionAsterWebhookStore for a read-only pass because its Cloudflare Workers 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- retain the existing CLI flags and exit codes\n- retain the current Cloudflare Workers operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"JunctionMapleQueueCoordinator: polish the last piece","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Read projects/junction/infra/modules/edge/main.tf and tell me whether JunctionWillowCodecService 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":"How does JunctionSlateEditorStore propagate cancellation through the Spring Boot boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'JunctionBeaconStoreFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[JunctionBeaconStoreFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/junction/apps/console/routes/usage.svelte:144: error: -[JunctionBeaconStoreFlowTests 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 '-[JunctionBeaconStoreFlowTests 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\nBring JunctionBeaconStoreFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Where did JunctionOspreyJobService's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ember: Incident timeline — INC-50132\n\n08:02 deploy JunctionBirchMigratorFlow 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 JunctionBirchMigratorFlow 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-50134: finish the compact JunctionBasilRunnerFlow filter experience\n\nRoute: /catalog/search\nSource: projects/junction/src/sync/reconcile.ts\nFramework: Cloudflare Workers\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nBring JunctionBasilRunnerFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-50133: retire the legacy replay path for JunctionSpruceDaemonFlow\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 JunctionSpruceDaemonFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Architect a gradual ownership transfer for JunctionMapleQueueService across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Translate the JunctionPrismCacheService setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Could the reasoning behind JunctionFrostPanelFlow's Cloudflare Workers choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Three teams extended JunctionJuniperCLIStore 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- retain the existing CLI flags and exit codes\n- retain the current Kotlin coroutines operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe target structure is settled; carry out the behavior-preserving edits rather than writing another strategy.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"$ pnpm test --filter JunctionCedarPolicyFlow\n RUN v3.2.4 /workspace/apps/console\n × JunctionCedarPolicyFlow > 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=50110 phase=resume storedCursor=seg-0183\n session=50110 phase=fetch requestCursor=seg-0183 pageSize=200\n session=50110 phase=commit receivedCursor=seg-0184 itemCount=0\n session=50110 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\nFind the source of this JunctionCedarPolicyFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Trace JunctionCinderAuthStore's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"The JunctionMarbleTokenStore 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":"Release engineering needs a JunctionDriftConsoleStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/junction/internal/auth/refresh.go: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: junctionnimbusformflow::scheduler::LeaseTask::flush\n at ./projects/junction/internal/auth/refresh.go:217:18\n 4: junctionnimbusformflow::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\nDetermine why JunctionNimbusFormFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"The behavior of JunctionLedgerGateService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/junction/packages/api/openapi.yaml. 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- retain the existing CLI flags and exit codes\n- retain the current Kafka operational envelope\n\nSeveral teams work in this logistics, WebAssembly, MySQL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-50140\n\n08:02 deploy JunctionKiteSchedulerFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the JunctionKiteSchedulerFlow 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":"In projects/junction/services/ledger/replay.go hat JunctionRainfallDBService ein sporadisches Problem im GraphQL-Ablauf. Vervollständige Responsive Layout, Empty- und Retry-State, Tastaturfokus, Dark Mode und Reduced Motion.\n\nRandbedingungen:\n- GraphQL weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf JunctionRainfallDBService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um JunctionRainfallDBService mit GraphQL kompatibel.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"de"}
{"prompt":"JunctionCraneWorkspaceCoordinator: ship, then assess","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Release engineering needs a JunctionMosaicGridStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"We need to move JunctionOrbitSyncService from the legacy store to Kotlin coroutines. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Frost: UI ticket DES-50128: finish the compact JunctionFlintTimelineFlow filter experience\n\nRoute: /catalog/search\nSource: projects/junction/Sources/App/SessionStore.swift\nFramework: Kotlin coroutines\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nBring JunctionFlintTimelineFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Garnet: Incident timeline — INC-50118\n\n08:02 deploy JunctionOpalRouterFlow 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 JunctionOpalRouterFlow 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":"JunctionIrisBatchCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Harbor: # projects/junction/ml/pipeline/features.py\n[worker.junctiondeltacanvasflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.junctiondeltacanvasflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.junctiondeltacanvasflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.JunctionDeltaCanvasFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-50123\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/junction/ml/pipeline/features.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Iris: projects/junction/apps/console/routes/usage.svelte has grown through several launches, and JunctionPineMetricsService 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- retain the existing CLI flags and exit codes\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to JunctionPineMetricsService and its direct tests\n\nThis repository spans logistics, WebAssembly, MySQL; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Compare the old and new JunctionQuartzPlayerStore 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":"What sequence would let JunctionLedgerGateFlow adopt Kafka with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Two engineers disagree about whether JunctionAtlasSearchService's cache is authoritative. Walk the reads and writes in projects/junction/ui/settings/PrivacyPane.tsx and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-50115: retire the legacy replay path for JunctionCloudReconcilerFlow\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 JunctionCloudReconcilerFlow 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":"Split JunctionSableParserStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Juniper: The minimum supported Cloudflare Workers version in projects/junction/src/sync/reconcile.ts 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":"diff --git a/projects/junction/infra/modules/edge/main.tf b/projects/junction/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/junction/infra/modules/edge/main.tf\n+++ b/projects/junction/infra/modules/edge/main.tf\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\nWire JunctionWillowCodecFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
data/round2-11.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "courier locations stop updating for a subset of couriers every evening:\n\n[location] 18:41:02 batch received, 412 couriers\n[location] 18:41:02 written to redis, 412 keys\n[location] 18:46:02 batch received, 388 couriers\n[location] 18:51:02 batch received, 214 couriers\n[location] 18:56:02 batch received, 88 couriers\n[app] courier c_9021 location publisher: android doze mode entered\n[app] courier c_9021 location publisher: wakelock released by system\n\nthe android app publishes from a foreground service, but only while the courier is actively holding the phone; the numbers drop as couriers pocket their phones after pickup", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "our partner changelog needs an entry for the proof-of-delivery threshold becoming public", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "the courier app should show why an offer was rejected, rather than the offer simply vanishing", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "a chain's IT team asked five questions about opening-hours propagation and our honest answers are all worse than they expect. write the documentation that answers them accurately, including the beta API's real limitations, without either overselling it or making the product sound unfinished 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": "courier screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "our health endpoint reports the dispatcher healthy while its zone has no couriers connected at all", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "the geometry kernel is wrapped in three adapter layers, each added because nobody wanted to touch the one below, and a simple call now crosses all three with a conversion at every boundary. collapse them to one adapter, keep the kernel's semantics exactly as they are, and tell me which conversions were silently lossy", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "gateway returns 503 for one upstream while envoy says the cluster is healthy:\n\nenvoy access log:\n[2026-07-29T11:02:14.881Z] \"POST /v1/orders HTTP/2\" 503 UF 0 91 30001 - \"-\" \"lumen-app/4.1\" \"8f2b1c40\" \"orders.internal\" \"10.4.2.71:8080\"\n\nresponse flags: UF = upstream connection failure\ncluster stats:\n upstream_cx_connect_timeout: 41882\n upstream_cx_active: 0\n upstream_rq_pending_overflow: 0\n health_check.attempt: 8412\n health_check.success: 8412\n membership_healthy: 4\n\nhealth checks pass on :8081 and traffic goes to :8080, which is a detail nobody remembered until today", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "flutter app shows stale order status for about a minute after delivery:\n\n[ws] connected wss://api.lumen.io/orders/88412/events\n[ws] event {\"type\":\"picked_up\",\"at\":\"18:52:11Z\"}\n[ws] event {\"type\":\"en_route\",\"at\":\"18:52:44Z\"}\n[ws] ping timeout, reconnecting (attempt 1)\n[ws] connected wss://api.lumen.io/orders/88412/events\n[ws] event {\"type\":\"en_route\",\"at\":\"18:52:44Z\"}\n[http] GET /orders/88412 → status: delivered, delivered_at: 18:58:02Z\n[ui] still showing \"on its way\"\n\non reconnect the socket replays from the last event it has rather than the current state, and the UI only updates from socket events", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "elixir cluster partitions during deploys and orders get double-assigned:\n\n11:02:14.101 [warn] :global name conflict for {:dispatcher, \"Z3\"}, resolving\n11:02:14.104 [info] node [email protected] down\n11:02:14.118 [info] :global re-registering {:dispatcher, \"Z3\"} on [email protected]\n11:02:14.882 [warn] duplicate assignment detected for order 88412: c_9021 and c_9044\n11:02:15.114 [info] node [email protected] up\n11:02:15.118 [warn] :global name conflict for {:dispatcher, \"Z3\"}, resolving\n\ndeploys are rolling, four nodes, and the dispatcher is a singleton per zone registered with :global", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "a bulk status endpoint for chains needs rate limits that accommodate 1,400 calls in a burst without letting anyone else do the same. decide the shape with me, then implement", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "couriers get assigned orders from closed restaurants during the dinner rush:\n\n[dispatch] 18:41:02.114 order 88412 ready_at=18:55 restaurant=r_4471 zone=Z3\n[dispatch] 18:41:02.118 candidate couriers: 12 within 2km\n[dispatch] 18:41:02.141 assigned to courier c_9021 (score 0.88, eta_to_pickup 6m)\n[dispatch] 18:41:02.882 courier c_9021 accepted\n[restaurant] 18:38:44.001 r_4471 status changed to closed (manual, staff)\n[dispatch] 18:41:12.004 order 88412 pickup failed: restaurant closed\n[dispatch] 18:41:12.009 order 88412 requeued, courier c_9021 released, compensation issued\n\nthe dispatcher reads restaurant state from a GenServer cache that refreshes every five minutes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "CAD files saved on windows won't open on mac, one customer's whole team is blocked:\n\nreading assembly.cadx:\n header ok, version 4.1, units mm\n reading part 1/41: ok\n reading part 2/41: ok\n reading part 12/41: error: referenced file not found: C:\\Users\\dana\\Projects\\brackets\\M6.cadpart\n reading part 13/41: error: referenced file not found: ..\\..\\shared\\fasteners\\M6.cadpart\n\nwe store both an absolute and a relative path for each referenced part, prefer the absolute, and fall back to the relative resolved against the assembly's directory using the platform separator", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "design doc for our order state machine, written a year ago. does it match what we run?\n\n## States\nplaced → confirmed → preparing → ready → picked_up → en_route → delivered\nAny state can transition to cancelled before picked_up. After picked_up, only delivered or failed.\n\n## Guarantees\n- Transitions are recorded in an append-only log and are the source of truth.\n- Clients derive current state from the log, so replay is always safe.\n- The websocket delivers every transition at least once, in order.\n\n## Not covered\nRestaurant-initiated cancellation after pickup. Partial refunds. Multi-courier handoff.\n\nwe added handoff in March, cancellation after pickup exists in the admin tool, and the socket replays from the client's last event rather than the log head", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "gateway's retry policy, which i think is amplifying incidents rather than smoothing them:\n\nretry_policy:\n retry_on: 5xx,reset,connect-failure,refused-stream\n num_retries: 3\n per_try_timeout: 10s\n retry_back_off: { base_interval: 0.025s, max_interval: 0.25s }\n retriable_status_codes: [503]\nrequest_timeout: 30s\n\nthe upstreams behind this include a payment service that is not idempotent on POST, and during the last incident our own retries tripled the load on a service that was already failing\n\nlast incident, from the upstream's side:\n inbound rps before: 1,200\n inbound rps during the incident: 3,910\n upstream_rq_retry: 41,882 in ten minutes\n upstream_rq_retry_overflow: 0\n our own error rate at the edge: 61%\n\nthe payment service owner has asked, twice, that we stop retrying their POSTs", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "redis config versus what the docs recommend for our access pattern:\n\n# ours\nmaxmemory: 8gb\nmaxmemory-policy: noeviction\nappendonly: yes\nappendfsync: everysec\nsave: 900 1 300 10 60 10000\ntimeout: 0\ntcp-keepalive: 300\n\nwe store courier locations (ephemeral, 30s TTL), dispatch state (must not be lost), and a session cache (rebuildable)\n\nthe noeviction policy means that when we hit 8gb, writes fail and dispatch stops, which happened last friday\n\nfriday's numbers when it filled:\n used_memory: 8.00G / 8.00G\n evicted_keys: 0\n rejected_connections: 0\n errors: OOM command not allowed when used memory > 'maxmemory' (41,882 in six minutes)\n keyspace: courier:loc:* 6.1G, dispatch:inflight:* 1.2G, session:* 0.7G\n\ndispatch stopped for eleven minutes and nothing recovered it until someone flushed the location keys by hand", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "document class has become the place everything goes. same behaviour, better seams:\n\nclass Document : public QObject {\n // owns the geometry tree\n // owns the undo stack\n // owns the selection\n // handles save, autosave and recovery\n // holds the plugin-visible IDocument implementation\n // emits 22 signals, of which the UI connects 19\n // has a static registry of open documents used by the plugin host\n};\n\n2,400 lines, and every one of those responsibilities has needed changing this quarter\n\nfor scale, this quarter's changes touched:\n save/autosave path 6 commits\n undo stack ownership 4 commits\n selection model 3 commits\n plugin-visible IDocument 5 commits\n the static open-documents registry 2 commits\n\nand every one of those commits also had to touch at least one unrelated part of the same file", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "restaurant cache refresh to 30 seconds", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "route inspector needs a diff view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "one availability check for couriers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "is one_for_all right for the zone tree?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "i'd like an honest read of whether a slow offer loop can block a whole zone's dispatch, given three sequential twenty-second offers in the dispatcher process, and the fix if it can", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "what does the dispatcher do with an offer that's accepted after the window closes", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "flutter analyze before the store release:\n\ninfo • Avoid `print` calls in production code • lib/services/ws_client.dart:88:5 • avoid_print\nwarning • The value of the field '_reconnectTimer' isn't used • lib/services/ws_client.dart:22:9 • unused_field\ninfo • Use 'const' with the constructor to improve performance • lib/widgets/order_card.dart:41:12 • prefer_const_constructors\nwarning • Missing case clause for 'handoff' • lib/models/order_state.dart:66:5 • missing_enum_case_clause\ninfo • Don't use 'BuildContext's across async gaps • lib/screens/order_screen.dart:141:22 • use_build_context_synchronously\n\n5 issues, and the missing enum case is the handoff state we added in march", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "pasted-context", "lang": "en"}
{"prompt": "gateway filters are copy-pasted per route with small differences:\n\n# routes/orders.yaml\nhttp_filters: [cors, jwt_auth, rate_limit, request_id, router]\n\n# routes/partners.yaml\nhttp_filters: [cors, jwt_auth, rate_limit, request_id, ext_authz, router]\n\n# routes/internal.yaml\nhttp_filters: [request_id, router]\n\n# routes/legacy.yaml\nhttp_filters: [cors, api_key_auth, rate_limit, router] # no request_id, which is why legacy traces are useless\n\nfour lists maintained by hand, and adding a filter means remembering all four files", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "elixir contexts have leaked into each other and the boundaries are gone:\n\nLumen.Orders.get_order/1 # used by Dispatch, Couriers, Admin, Billing\nLumen.Dispatch.assign/2 # calls Orders.update_state/2 directly\nLumen.Couriers.available?/1 # duplicated in Dispatch, as above\nLumen.Billing.charge/1 # called from Orders.deliver/1 inline\nLumen.Admin.force_reassign/2 # calls Dispatch internals via :sys.replace_state\n\nfive contexts, no boundaries, and the admin one reaches into a GenServer's state to fix production problems", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "modeller crashes when undoing a boolean operation on a large assembly:\n\nThread 1 \"cadmodeller\" received signal SIGSEGV, Segmentation fault.\n0x00007ffff7a2c118 in cad::geom::BRepShape::~BRepShape() at src/geom/brep.cpp:412\n412\t for (auto* face : faces_) delete face;\n(gdb) bt\n#0 cad::geom::BRepShape::~BRepShape\n#1 0x0000555555601a44 in cad::undo::BooleanCommand::undo() at src/undo/boolean.cpp:141\n#2 0x00005555556220c8 in cad::undo::UndoStack::undo() at src/undo/stack.cpp:88\n#3 0x00007ffff7b0a112 in QAction::triggered()\n(gdb) p faces_.size()\n$1 = 41882\n\nthe boolean result shares face pointers with its operands, and undo deletes the result while the operands are still live", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "nuestro gateway devuelve 429 a un cliente que está muy por debajo de su límite:\n\ncliente: partner_4471, límite contratado 1000 rpm\nmétricas del gateway:\n ratelimit_hits{descriptor=\"partner_4471\"} 412 rpm\n ratelimit_over_limit{descriptor=\"partner_4471\"} 188 rpm\n ratelimit_error{...} 0\n\nconfiguración:\n descriptors:\n - key: partner_id\n rate_limit: { unit: minute, requests_per_unit: 1000 }\n - key: partner_id\n value: partner_4471\n rate_limit: { unit: second, requests_per_unit: 5 }\n\nel segundo descriptor lo añadió alguien hace meses para una prueba de carga", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "es"}
{"prompt": "before this goes near production, is the supervision strategy right?\n\ndefmodule Lumen.Dispatch.ZoneSupervisor do\n use Supervisor\n\n def init(zone) do\n children = [\n {Lumen.Dispatch.Dispatcher, zone},\n {Lumen.Dispatch.CourierCache, zone},\n {Lumen.Dispatch.RestaurantCache, zone}\n ]\n Supervisor.init(children, strategy: :one_for_all, max_restarts: 3, max_seconds: 5)\n end\nend\n\nthe dispatcher holds in-flight assignments in its state, the caches are refreshed every five minutes from postgres, and a restart loses whatever the dispatcher was holding", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "undo implementation, which i inherited and which is the source of two crash clusters:\n\nclass BooleanCommand : public Command {\n BRepShape* result_;\n BRepShape* lhs_;\n BRepShape* rhs_;\npublic:\n void redo() override {\n result_ = geom::boolean_union(lhs_, rhs_); // shares face pointers with operands\n doc_->replace({lhs_, rhs_}, result_);\n }\n void undo() override {\n doc_->replace({result_}, {lhs_, rhs_});\n delete result_;\n }\n};\n\nthe undo stack holds a hundred of these, documents can be closed with the stack non-empty, and geom::boolean_union is documented as \"may reference input geometry\"", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "rate limit configuration we ship to customers, which i suspect nobody fully understands:\n\ndomain: lumen_api\ndescriptors:\n - key: partner_id\n rate_limit: { unit: minute, requests_per_unit: 1000 }\n - key: partner_id\n value: partner_4471\n rate_limit: { unit: second, requests_per_unit: 5 }\n - key: partner_id\n descriptors:\n - key: endpoint\n value: /v1/orders\n rate_limit: { unit: minute, requests_per_unit: 100 }\n\nwhen a request matches several descriptors, which apply? all of them, the most specific, or the first match? our documentation says one thing and the behaviour looks like another", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "file format's reference handling, which is why cross-platform assemblies break:\n\nstruct PartRef {\n std::string absolute_path; // as saved on the authoring machine\n std::string relative_path; // relative to the assembly file, native separators\n std::optional<Uuid> content_id; // added in 4.0, populated only for new refs\n};\n\nPartRef resolve(const PartRef& ref, const fs::path& assembly_dir) {\n if (fs::exists(ref.absolute_path)) return load(ref.absolute_path);\n auto rel = assembly_dir / ref.relative_path;\n if (fs::exists(rel)) return load(rel);\n throw NotFound(ref.absolute_path);\n}\n\ncontent_id exists and is never used in resolution; relative paths keep whatever separator the authoring platform used", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the modeller's 4.2 release:\n\n41c9e0b fix(undo): boolean undo no longer frees geometry still referenced by operands\n88f21c0 feat(files): assemblies resolve references by content id before falling back to paths\nc0aa774 fix(autosave): autosave writes to a temporary file and renames, never truncates in place\n2e91b45 feat(perf): assembly load is now parallel, 41 parts in 2s instead of 14s\naa30f19 fix(ui): the measurement tool no longer snaps to hidden geometry\n9c1d004 chore: minimum macOS is 13, minimum Windows is 10 22H2\n4410bb7 feat(export): STEP export preserves assembly structure\nb77e910 fix(undo): the undo stack is cleared on document close rather than leaked\n\nour users are mechanical engineers; two of these are data-loss fixes and should be impossible to miss", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "three modules decide whether a courier is available and they disagree:\n\n# dispatch/assign.ex\ndefp available?(c), do: c.status == :online and c.current_assignment == nil\n\n# dispatch/stacking.ex\ndefp can_take_more?(c), do: c.status in [:online, :delivering] and length(c.assignments) < 2\n\n# admin/courier_view.ex\ndef available?(c), do: c.status == :online and c.last_seen_at > minutes_ago(2)\n\nstacking is the newest and the only one that considers the two-assignment limit; the admin view is what support looks at when a courier complains they're getting no work", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "opening-hours API the chain customer wants, currently a beta nobody supports:\n\nPUT /v1/restaurants/{id}/status { open: bool, reason?: string, until?: timestamp }\n must take effect in dispatch within 30 seconds, contractually\n a close with `until` reopens automatically; without it, the restaurant stays closed until reopened\n orders already accepted are unaffected, which the customer has agreed to but wants stated\n the caller may be the chain's own system, so authentication is a chain-scoped key covering many restaurants\n we must record who closed it and why, and expose that on GET for their own audit\n they will call this for 1,400 restaurants and expect bulk semantics — one call per restaurant is acceptable but rate limits must accommodate it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "el mapa no centra en la recogida", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "es"}
{"prompt": "Autosave darf nicht in-place schreiben", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "de"}
{"prompt": "doc comments on the plugin interface", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "why is mTLS costing us 40ms?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "order as you see fit", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "we owe the restaurant chain a written explanation of why couriers kept arriving at locations they had closed, and their complaint is reputational rather than financial. write the incident report for a non-technical operations audience, honest about the five-minute cache, and clear about what changes and by when i've already spent an afternoon on it and got nowhere useful.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "assignments occasionally go to two couriers during a rolling deploy and the logs show :global resolving a name conflict at exactly that moment. work through what happens to the dispatcher's in-flight state when the registration moves, before we decide whether the answer is durability or a different registry if the answer is that it's fine as it is, that's a useful answer too.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "staging has four upstreams and prod has forty-one, with the same connection pool settings", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "per-partner circuit breaking in the gateway, so one slow partner can't take the pool", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "CAD plugin API, which four customers write against with only a header file for documentation:\n\nclass IPlugin {\npublic:\n virtual const char* name() const = 0;\n virtual int apiVersion() const = 0; // must equal CAD_PLUGIN_API_VERSION\n virtual void onDocumentOpened(IDocument*) {}\n virtual void onSelectionChanged(const ISelection&) {}\n virtual bool onCommand(const char* id, ICommandContext&) { return false; }\n virtual void registerCommands(ICommandRegistry&) {}\n};\n\nthings only we know: onSelectionChanged is called on the UI thread and blocking it freezes the app; IDocument pointers are invalidated on close with no notification; onCommand returning true suppresses the built-in command of the same id, including our own; and apiVersion mismatches are silently ignored, the plugin simply never loads\n\nwrite the plugin developer guide", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "gateway's config in staging and prod, and staging never reproduces our timeouts:\n\n# staging\nconnect_timeout: 5s\nrequest_timeout: 30s\nretry: { num_retries: 3, per_try_timeout: 10s }\nhealth_check: { interval: 10s, unhealthy_threshold: 3, port: 8080 }\ncircuit_breakers: { max_connections: 1024, max_pending_requests: 1024 }\nupstreams: 4\n\n# prod\nconnect_timeout: 30s\nrequest_timeout: 30s\nretry: { num_retries: 3, per_try_timeout: 10s }\nhealth_check: { interval: 10s, unhealthy_threshold: 3, port: 8081 }\ncircuit_breakers: { max_connections: 1024, max_pending_requests: 1024 }\nupstreams: 41", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the courier app's active delivery screen, flutter:\n\nActive delivery\n- Map fills the top two thirds, route to the next waypoint, courier position as a heading arrow; recentres on a 5 second idle.\n- Bottom card: address, customer name, order items collapsed to a count, and the primary action for the current stage (Arrived / Picked up / Delivered).\n- The primary action is a slide-to-confirm control, not a button, because accidental taps cost us orders.\n- Stacked deliveries show a second card behind the first with the next drop's ETA; swiping up reveals it.\n- Offline: the screen keeps working from cached data, actions queue with a visible \"will send when back online\" state, and the slide control still works.\n- Battery: the screen must not keep the display awake; navigation hand-off to the system maps app is a single tap.\n- Everything must be usable one-handed with gloves on, which means 56dp minimum targets and no long-press-only actions.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "redis policy to allkeys-lru for locations", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "one websocket client for all screens", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "document the 20 second offer window", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "courier API is used by our own flutter app and two partner fleets, and it's documented in a google doc that nobody has updated since the offer window changed. write the reference properly, with the silent drop of over-frequent location updates and the unpublished proof-of-delivery threshold stated plainly rather than discovered by integration partners the hard way", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "our gateway config lives in two repos owned by two teams and neither validates the other's assumptions", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "the offer window is twenty seconds in the dispatcher and twenty-five in the app, which makes legitimate late accepts look like client bugs and has generated a month of misdirected support tickets. align them, and write the short note for support explaining what the symptom actually was context if it helps: this has been open since before i joined the team.", "purpose": "quickFix", "secondary": "writing", "mixed": true, "difficulty": 0.45, "slice": "mixed", "lang": "en"}
{"prompt": "a walkthrough of how an order reaches a courier's phone would help before i touch the socket layer", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "courier scoring function has grown a term per incident, its weights were tuned by hand three times, and nothing about it is tested. restructure it so each term is separately testable and the weights live in configuration, keeping the ranking identical for a replayed evening of real assignments i'd like enough detail that i can hand it to someone else to finish.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "our internal page on the dispatch pipeline stops at \"the dispatcher assigns the order\" and everything after that — offers, acceptance, stacking, handoff — is folklore held by two people. write the page properly, following one order from placement to delivery and naming every service and queue it passes through nobody has trusted this code for about a year, which is part of the problem.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "the measurement tool snaps to hidden geometry, which two customers have described as actively dangerous because a measurement that looks right can be taken from a suppressed part. change the snapping to respect visibility, keep the existing snap priorities otherwise, and make sure suppressed parts stay excluded when they're temporarily shown", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "couriers sent to closed restaurants", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "gateway retries 503s and connect failures three times by default, including for POSTs to a payment service that is not idempotent, and this amplified both of our last two incidents. work through what a defensible retry policy looks like per route class, how we'd enforce idempotency where retries are allowed, and how we stop a well-meaning default from doing this again", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "elixir contexts have leaked into each other to the point where the admin tool reaches into a GenServer's state to fix production problems. i'd rather agree what the boundaries should be, and what each context owns, than keep adding functions wherever they're convenient — with a view on which violations are worth fixing first", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "route inspector is what we open during incidents and it currently shows the config as written rather than as effective, which has misled us twice. build the effective-config view with provenance per value, the request-id lookup, and inline flags for dangerous settings 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": "flutter app has three websocket clients with three reconnect strategies and none of them refetches state on reconnect. unify them, then document the reconnect contract so the next screen doesn't invent a fourth", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "restaurant portal ignores half our design tokens and removes focus styles on three components. bring it onto the tokens, and tell me which colour changes will be visible to restaurants who've used this daily for two years", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like to understand how the undo stack interacts with document close, because i suspect it leaks", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "is our health check actually checking the port that serves traffic", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does the location endpoint make about ordering when a phone uploads a backlog", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "a short note on why we're moving dispatcher state to postgres, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "modeller's autosave corrupts files when the app is killed mid-save:\n\nsave sequence from the log:\n 11:02:14.101 autosave started, target /Users/dana/proj/assembly.cadx\n 11:02:14.104 truncating existing file\n 11:02:14.882 wrote header + 12/41 parts\n <process killed>\n\non next open:\n error: unexpected end of file at offset 8412114 (expected 41882002)\n no backup found; autosave overwrites in place and .bak is only written on explicit save\n\nthe customer lost four hours of work and is understandably furious", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "requests through the mesh get 40ms slower after we enabled mTLS, which is more than we expected:\n\nbefore:\n p50 8ms p95 22ms p99 41ms\nafter:\n p50 12ms p95 61ms p99 188ms\n\nenvoy stats:\n ssl.handshake: 41,882/min\n ssl.session_reused: 118/min\n upstream_cx_total: 41,882/min\n upstream_cx_http2_total: 0\n\nour sidecars are configured for HTTP/1.1 upstreams with no connection pooling changes, so every request appears to be establishing a new TLS session\n\nsidecar config, the relevant part:\n http_protocol_options: { explicit_http_config: { http_protocol_options: {} } }\n common_http_protocol_options: { idle_timeout: 1s }\n circuit_breakers: { max_connections: 1024 }\n transport_socket: { name: envoy.transport_sockets.tls }\n\nthe one second idle timeout was copied from an example config a year ago and nobody has questioned it since", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "bitte einmal drüberschauen, das läuft im Abendgeschäft:\n\ndef assign(order, couriers) do\n couriers\n |> Enum.filter(&available?/1)\n |> Enum.map(&{&1, score(&1, order)})\n |> Enum.sort_by(fn {_, s} -> -s end)\n |> Enum.take(3)\n |> Enum.reduce_while(nil, fn {courier, _}, _ ->\n case offer(courier, order, timeout: 20_000) do\n :accepted -> {:halt, courier}\n _ -> {:cont, nil}\n end\n end)\nend\n\nbis zu 20 Sekunden pro Kurier, drei Kuriere nacheinander, und der aufrufende Prozess ist der Dispatcher für die ganze Zone", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "de"}
{"prompt": "query behind our restaurant dashboard, which times out for chains:\n\nSELECT r.id, r.name,\n count(*) FILTER (WHERE o.state = 'delivered' AND o.placed_at > now() - interval '7 days') AS delivered_7d,\n avg(EXTRACT(epoch FROM (o.picked_up_at - o.ready_at))) FILTER (WHERE o.picked_up_at IS NOT NULL) AS avg_wait,\n (SELECT count(*) FROM order_issues i WHERE i.restaurant_id = r.id AND i.resolved_at IS NULL) AS open_issues,\n (SELECT avg(rating) FROM reviews rv WHERE rv.restaurant_id = r.id AND rv.created_at > now() - interval '30 days') AS rating\nFROM restaurants r\nLEFT JOIN orders o ON o.restaurant_id = r.id\nWHERE r.chain_id = $1\nGROUP BY r.id, r.name;\n\none chain has 1,400 restaurants and orders is 400M rows partitioned by month", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the assembly-won't-open problem, they need to become a customer-facing article:\n\n- happens when an assembly authored on windows is opened on mac or linux, or vice versa\n- the absolute path is tried first and obviously fails on the other platform\n- the relative path then fails too if it was saved with backslashes\n- workaround is opening each missing part manually once, which rewrites the reference\n- for a 40-part assembly that's twenty minutes of clicking\n- files saved by 4.0 or later have a content id we could use but don't\n- customers on mixed-platform teams hit this every time they share a file\n\nwrite the article, including the workaround, and separately tell me what the real fix looks like", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "courier-facing API, which the flutter app and two partner fleets use, documented in a google doc:\n\nPOST /v1/couriers/{id}/location { lat, lon, accuracy_m, heading, speed_kph, battery_pct, at }\n accepted at up to 1 Hz; anything faster is silently dropped, not rejected\n a location older than 60 seconds is ignored, which partners discover by having their history not appear\nPOST /v1/offers/{id}/respond { accept: bool, reason? }\n must be within the 20 second offer window; late responses get 409 and the offer is already gone\nGET /v1/couriers/{id}/assignments\n returns current and next assignment; \"next\" only exists during a stacked delivery\nPOST /v1/assignments/{id}/events { type: \"arrived\"|\"picked_up\"|\"delivered\", at, proof? }\n proof is required for delivered when the order is high value, and the threshold is not published\n\nwrite the reference; the silent drops and the unpublished threshold are what partners keep asking about", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "notes from the incident review, we owe the restaurants an explanation:\n\n18:41 couriers begin receiving orders from restaurants that had closed\n18:52 pattern identified: closures made in the last five minutes are not seen by dispatch\n19:04 restaurant cache refresh reduced from five minutes to thirty seconds as a stopgap\n19:20 issue stops recurring\n21:00 44 orders affected, all requeued or refunded, 12 couriers compensated for wasted trips\n\nroot cause: the dispatcher reads restaurant open/closed state from an in-memory cache refreshed on a timer, with no invalidation when a restaurant changes state\n\nthe restaurants' complaint is that they closed and we kept sending couriers, which made them look bad to customers", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "les notes de la réunion d'architecture, à transformer en document de décision :\n\n- la passerelle applique aujourd'hui quatre politiques différentes selon l'ancienneté de la route\n- personne ne sait laquelle s'applique quand plusieurs descripteurs correspondent\n- la documentation dit « le plus spécifique gagne », le code applique tous les descripteurs correspondants\n- les partenaires configurent leurs propres limites via un fichier YAML que nous appliquons sans validation\n- une limite mal écrite peut aujourd'hui bloquer un partenaire entier, ce qui est déjà arrivé deux fois\n- l'équipe propose un seul modèle explicite, avec validation au moment de l'écriture\n\nrédige la note de décision avec les options et une recommandation", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "fr"}
{"prompt": "operator's guide for the gateway is a single page from when we had one cluster. what's true now:\n\n- routes are defined in git, applied by a controller, and a bad route can be rolled back by reverting\n- rate limit descriptors live in a separate repo owned by the partnerships team, applied without validation\n- the mTLS rotation is automatic but the root has to be rotated manually every two years, and it's due in march\n- an upstream that fails health checks is ejected for 30 seconds, which is shorter than most of our deploys\n- retries are on by default for 503 and connect failures, including for non-idempotent POSTs\n- there is no per-partner circuit breaking; one slow partner can consume the whole connection pool\n\nwrite the operator's guide, and mark the four things here that are actually dangerous defaults", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "questions the restaurant chain's IT team sent before signing, which need a proper answer:\n\n\"How quickly does a change to our opening hours take effect in your dispatch system? If we close a location for an emergency, what is the worst case before couriers stop being sent? Do you have an API for this or is it only the portal? What happens to orders already accepted when we close? Can we see, after the fact, which orders were sent to a closed location and why?\"\n\nour honest answers are: up to five minutes, five minutes, portal only with an API in beta, they stay assigned, and no. write the response as documentation rather than an email, and don't oversell what the beta API does", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "内部向けのオンコール手順書がまだありません。現状、チームが実際にやっていることは次の通りです:\n\n- 最初に見るのはゾーン別のディスパッチ遅延ダッシュボード、5 分を超えたら異常\n- 遅延が特定ゾーンだけなら、そのゾーンの dispatcher プロセスを再起動する（進行中の割り当ては失われるが、20 秒以内に再割り当てされる）\n- 全ゾーンで遅延している場合は redis の接続数を確認する、上限に張り付いていることが多い\n- 「注文が届かない」という問い合わせは、まず websocket ではなく HTTP の状態を見る（websocket は再接続時に最新状態を返さない）\n- デプロイ中の :global 名前衝突は既知の問題で、二重割り当てが起きるが自動で解消される\n- 夜間に redis を再起動してはいけない。クーリエの位置情報がすべて消える\n\nこれをオンコール手順書としてまとめてください。優先順位は夜中に起こされた人が最初に必要とする順で\n\n参考までに、現在のダッシュボードとコマンドはこれだけです:\n\n dispatch_assign_seconds{zone=\"Z3\"} p95 = 6.2s (閾値 5s)\n redis_connected_clients = 9,812 / 10,000\n courier_location_batch_size{zone=\"Z3\"} = 88 (通常は 400 前後)\n\n # ゾーンの dispatcher を再起動する\n bin/lumen rpc 'Lumen.Dispatch.ZoneSupervisor.restart(\"Z3\")'\n # 進行中の割り当てを確認する\n bin/lumen rpc 'Lumen.Dispatch.Dispatcher.inflight(\"Z3\") |> length()'\n\nこれらのコマンドはどこにも書かれておらず、Slack の過去ログを検索して見つけるしかありません", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "ja"}
{"prompt": "credo and dialyzer on the elixir app, gate goes on next week:\n\n┃ [W] ↗ Function body is nested too deep (max_nesting: 2)\n┃ lib/lumen/dispatch/assign.ex:88 #{Lumen.Dispatch.assign/2}\n┃ [R] ↗ Function is too complex (CC is 14, max is 9)\n┃ lib/lumen/dispatch/score.ex:22\n┃ [W] ↗ There should be no unused aliases\n┃ lib/lumen/orders/state.ex:4\n\ndialyzer:\nlib/lumen/dispatch/assign.ex:141:no_return\nFunction offer/3 has no local return\nlib/lumen/orders/state.ex:66:pattern_match\nThe pattern can never match the type {:error, _}\n\n3 credo issues, 2 dialyzer findings, and the no_return one looks like it matters", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "clang-tidy on the modeller, and two of these are our crash clusters:\n\nsrc/undo/boolean.cpp:141:9: warning: 'delete' on a pointer that may be shared [cppcoreguidelines-owning-memory]\nsrc/geom/brep.cpp:412:5: warning: loop deleting raw pointers; consider a container of unique_ptr [modernize-loop-convert]\nsrc/io/save.cpp:88:13: warning: file is truncated before the write succeeds [bugprone-unsafe-file-handling]\nsrc/ui/measure.cpp:22:1: warning: function exceeds recommended size [readability-function-size]\nsrc/plugin/host.cpp:66:22: warning: virtual call in destructor [clang-analyzer-optin.cplusplus.VirtualCall]\n\n5 warnings, and save.cpp:88 is the autosave corruption we've been arguing about", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependabot on the elixir app, three open:\n\nphoenix 1.7.12 → 1.7.18 (patch series; changelog mentions a change to channel reconnect behaviour)\necto_sql 3.11.1 → 3.12.1 (minor; migration lock behaviour changed for multi-node deploys)\nfinch 0.18.0 → 0.19.0 (minor; default pool size per host changed from 50 to 10)\n\nour dispatcher runs on four nodes and does migrations on boot; the courier API is the heaviest user of finch", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "os alertas do dispatch acordam-nos por nada e falham no que importa:\n\n- alert: DispatchLatency\n expr: histogram_quantile(0.95, dispatch_assign_seconds_bucket) > 5\n for: 1m\n labels: { severity: page }\n\n- alert: CourierOffline\n expr: up{job=\"courier-api\"} == 0\n for: 0m\n labels: { severity: page }\n\n- alert: RedisMemory\n expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.95\n for: 5m\n labels: { severity: ticket }\n\ncomportamento real: a latência passa de 5s em todas as noites às 19h durante o pico; o redis encheu na sexta-feira e o alerta era apenas um ticket, pelo que ninguém viu antes de o dispatch parar durante onze minutos", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "pt"}
{"prompt": "nuestro cliente de websocket en flutter está escrito tres veces, una por pantalla:\n\n// order_screen.dart\nfinal ws = WebSocketChannel.connect(uri); ws.stream.listen(_onEvent, onDone: _reconnect);\n\n// courier_screen.dart\nfinal ws = IOWebSocketChannel.connect(uri, pingInterval: Duration(seconds: 20));\nws.stream.listen(_onEvent, onError: (_) => _reconnectWithBackoff());\n\n// tracking_screen.dart\nStreamSubscription? _sub;\nvoid _connect() { _sub = channel.stream.listen(_onEvent); }\n// sin reconexión en absoluto\n\ntres estrategias de reconexión, dos de ellas sin backoff, y ninguna vuelve a pedir el estado actual al reconectar", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "es"}
{"prompt": "scoring function has grown a term per incident and nobody can explain the weights:\n\ndefp score(courier, order) do\n distance_score(courier, order) * 0.4 +\n acceptance_rate(courier) * 0.2 +\n idle_time(courier) * 0.15 +\n vehicle_fit(courier, order) * 0.1 +\n zone_affinity(courier, order) * 0.05 +\n batching_bonus(courier, order) * 0.05 +\n (if courier.new?, do: 0.05, else: 0.0) -\n (if recently_rejected?(courier, order.restaurant_id), do: 0.3, else: 0.0)\nend\n\nthe weights were tuned by hand in three separate incidents, the rejection penalty was added last week, and nothing is tested", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, thinking before code:\n\nDISP-330 — Dispatcher state durability\nThe zone dispatcher is a GenServer holding in-flight assignments in memory, registered via :global, restarted by a one_for_all supervisor. A crash or a rolling deploy loses whatever it was holding, and during deploys :global name conflicts have produced duplicate assignments. The proposal is to move in-flight state into postgres with the GenServer as a cache, or to adopt a proper distributed process registry. Concerns: assignment decisions are latency sensitive (we have a 20 second offer window); postgres is already the bottleneck at dinner peak; and the team has no experience with the alternatives.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "compliance requirement for courier data, which legal has now put a date on:\n\n\"Location data of couriers may be retained only for the duration necessary to complete and account for a delivery, and in any case no longer than 90 days. Couriers must be able to obtain a copy of their location history and to have it erased after that period. Aggregated analytics derived from location data must not permit re-identification of an individual courier. Access by staff must be logged and justified.\"\n\nwe keep raw location points indefinitely in redis and postgres, our analytics tables are keyed by courier id, and access is a support tool with no logging. i want the plan in order of legal risk", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the gateway's route inspector in our console, which we use during incidents:\n\nRoute inspector\n- Left: route tree grouped by domain, with a health dot per route rolling up its upstreams.\n- Main: the effective configuration for the selected route — filters in order, timeouts, retries, rate limits — with each value showing where it came from (route, domain default, or global).\n- A diff view against the last applied revision, with the git commit and author.\n- Live traffic strip: requests per second, error rate and p99 for the last 15 minutes, updating every 5 seconds.\n- A \"why did this request fail\" box: paste a request id, get the matched route, the filters that ran, and which one returned the error.\n- Dangerous values (retries on non-idempotent methods, no circuit breaker) are flagged inline with an explanation.\n- Read-only for everyone except the two people who can apply changes, and applying goes through git, never directly.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings for the modeller's UI, from a government customer's procurement review:\n\n1. The ribbon is navigable only by mouse; keyboard focus skips from the menu bar to the viewport.\n2. Tool state (active/inactive) is conveyed by a subtle background tint failing contrast at 1.9:1.\n3. The measurement panel updates values without announcing them.\n4. Modal dialogs do not return focus to the invoking control on close.\n5. The viewport has no keyboard alternative for selection, which makes the whole product unusable without a mouse.\n6. Error toasts disappear after 3 seconds regardless of length or importance.\n7. High-contrast mode on Windows is ignored entirely; the app draws its own theme.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "schema we agreed for courier location retention, now it needs building:\n\nCREATE TABLE courier_pings (\n courier_id uuid NOT NULL,\n at timestamptz NOT NULL,\n point geography(Point, 4326) NOT NULL,\n accuracy_m real,\n assignment_id uuid,\n PRIMARY KEY (courier_id, at)\n) PARTITION BY RANGE (at);\n\npartitions are daily; anything older than 90 days must be dropped automatically; a courier's export must be servable within 24 hours of request; erasure must remove pings but keep the delivery record itself; and the analytics tables that currently key on courier_id need a plan of their own because they're derived from this", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "health check port should be 8080", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "drop the stale partner_4471 descriptor", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "tip screen says \"Thankyou\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "missing handoff case in the enum switch", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "no retries on POST /v1/payments", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "CAD team's list, with the enterprise renewals in mind:\n\n- autosave must never truncate in place; write-and-rename plus a real backup chain\n- undo must stop sharing ownership of geometry with live objects\n- cross-platform references need to resolve by content id, which we already store\n- the document class needs splitting before anyone can safely touch any of the above\n- plugin API needs documenting; four customers are guessing\n- assembly load is single-threaded and takes 14 seconds for a 41-part assembly\n\ntwo engineers, and one enterprise renewal decision in eight weeks", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "request_id filter missing on legacy routes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "design tokens versus what the restaurant portal actually uses:\n\ntokens:\n color.surface #FFFFFF / #101317\n color.text.default #10151A / #E8EDF2\n color.accent #E8562A\n color.status.late #B42318\n color.status.ok #067647\n space 4/8/12/16/24/32, radius 6/10/14, focus 2px solid accent, offset 2px\n type: title 20/26, body 14/20, caption 12/16\n\nthe portal: seven hardcoded colours including two versions of the accent, focus styles removed on three interactive components, paddings of 5/7/13/18, and a late-order indicator that is colour-only\n\nbring it onto the tokens, restore focus styles, and give the late indicator a non-colour cue", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "RedisMemory should page, not ticket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "connect timeout 30s in prod is too long", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "slide-to-confirm instead of a button", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "courier location retention has a legal deadline and no design. work through what we keep, for how long, and what erasure means for the analytics derived from it, then implement the partition drop job as the first concrete piece", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "our dispatch code reaches into the orders context in eleven places to update state directly, which is why the state machine's guarantees are aspirational rather than enforced. route those writes through one function that validates transitions, keep every current transition working exactly as it does, and give me the list of transitions that turn out to be invalid under the documented machine", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the same \"is this order late\" calculation exists in four places and they disagree by minutes:\n\n# dispatch/lateness.ex\ndef late?(order), do: DateTime.diff(DateTime.utc_now(), order.promised_at) > 0\n\n# restaurant_portal/live/orders.ex\ndef late?(order), do: DateTime.diff(DateTime.utc_now(), order.ready_at) > 300\n\n# courier_app (dart)\nbool isLate(Order o) => DateTime.now().isAfter(o.promisedAt.add(Duration(minutes: 2)));\n\n# analytics/sql/late_orders.sql\nWHERE delivered_at > promised_at + interval '5 minutes'\n\nthe portal is what restaurants see and complain about, the analytics number is what we report to chains in their monthly review, and the two have never matched. i want one definition, applied everywhere, with the analytics figure as the reference because that's the number in contracts", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "stacked delivery card behind the first", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "56dp targets, couriers wear gloves", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "tool state tint fails contrast", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "エラーのトーストが3秒で消えます", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "ja"}
{"prompt": "late orders are red only", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "ribbon can't be reached by keyboard", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "map keeps the screen awake", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "focus doesn't return after a dialog", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "filter lists from one template", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "pull save/recovery out of Document", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "un seul module pour le scoring", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "fr"}
{"prompt": "`ready_at` naming across contexts", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "extract the offer loop from assign", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "inline `zone_affinity`, one caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "context boundaries in the elixir app", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "changelog for modeller 4.2", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota para os restaurantes sobre o incidente", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "pt"}
{"prompt": "summarise the durability proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the autosave fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "which descriptor wins on a match?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "¿el undo libera geometría compartida?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "es"}
{"prompt": "can retries make an outage worse?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "walk me through offer acceptance", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "undo crashes on large assemblies", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "one upstream 503s while healthy", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "warum verdoppeln sich Zuweisungen beim Deploy?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a zone's dispatch backlog", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "dispatch thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "crack on", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "fewer pages tonight", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo del gateway, continúa", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "es"}
{"prompt": "that CAD thing again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "straighten it out", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "as we discussed", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "doc for legal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "nothing risky today", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "eyes on this one", "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": "pick something up", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "zone dispatcher holds in-flight assignments in memory, is registered with :global, and loses everything it was holding on a restart, which during rolling deploys has produced both dropped assignments and duplicated ones. i want the options for making that state durable worked through properly — postgres-backed with the process as a cache, a distributed registry, or something else — with the twenty second offer window and the dinner-peak database load as the constraints that actually bind", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "autosave truncating in place has now cost us two enterprise renewals and the fix is obviously write-and-rename, but the wider question is what our data-durability story should be — backup chains, crash recovery, what we promise a customer whose laptop dies mid-save. i'd like that written down as a position before we patch the one function everyone is angry about", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "couriers stop publishing location when their phone goes into doze, which is most of an evening shift, and our current answer is a foreground service that android increasingly ignores. i want the realistic options — platform APIs we're not using, batching with the geofence API, accepting lower resolution — with the impact on dispatch quality for each", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "document class in the modeller owns geometry, undo, selection, saving and the plugin surface, and every one of those has needed changing this quarter. before anyone splits it i'd like agreement on what the pieces are and in what order they move, because a half-finished split is worse than the current mess", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "four customers write plugins against a header file and a hope, and the behaviours that bite them — UI-thread callbacks, invalidated document pointers, silently ignored version mismatches — are exactly the ones we've never written down. write the plugin developer guide covering the lifecycle, the threading rules and the failure modes the sooner we know roughly how big this is, the better for planning.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "gateway's operator guide describes a single cluster from three years ago, while today routes come from git, rate limits from a repo owned by another team with no validation, and four of our defaults are actively dangerous. write the current guide and mark those defaults clearly rather than burying them in a table this has come up in three separate reviews now and never gets done.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me what the boolean undo actually frees, given that the union result shares face pointers with its operands and the geometry library documents itself as \"may reference input geometry\". read the command, the shape destructor and the library's ownership rules together and tell me exactly what is double-freed and when", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "rate limit configuration has three descriptors that can all match one request, our documentation says the most specific wins, and the observed behaviour suggests all of them apply. work out what the implementation really does, including the nested descriptor case, before i tell a partner their limit is what they think it is flag anything you'd want to change before doing it rather than after.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "order state machine's design doc promises an append-only log as the source of truth and a socket that delivers every transition in order, and i believe neither is true any more. go through the doc claim by claim against the code, including the handoff state we added in march there's no rush on this week specifically, but it keeps costing us time.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "three modules decide whether a courier is available and they disagree about stacked deliveries, staleness and the two-assignment limit, which is why support and dispatch tell couriers different things. consolidate onto one predicate, with the stacking rules as the reference behaviour, and list which couriers become newly eligible or ineligible as a result the last person who touched this left, so there's nobody to ask.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "gateway filter chains are maintained by hand in four route files and the legacy one is missing request_id, which is why legacy traces are useless. generate the chains from one declaration with per-route exceptions, keeping the applied configuration byte-identical for the three routes that are currently correct we've been burned by guessing at this before, so evidence over instinct please.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "active delivery screen has to work one-handed, with gloves, on a phone that's about to die, while the courier is walking. build it to the spec — slide to confirm, queued actions when offline, no screen wake-lock — and tell me which parts of the current screen actively fight those constraints", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "before we make dispatcher state durable i want the design agreed — what's authoritative, what the process caches, how a handover works mid-offer — and then the assignment write path implemented against it so we can measure the latency cost at peak a rough ordering matters more to me than a complete answer right now.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "opening-hours API needs to go from beta to something we'd sign a contract on, which is a design question about propagation guarantees before it's an implementation. settle the semantics with me, then build the write path and the dispatch invalidation this is the third time it's bitten us and i'd like it to be the last.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "das Dokument-Objekt im Modeller macht alles gleichzeitig und blockiert jede weitere Änderung. Ich hätte gern zuerst einen Schnittplan, welche Verantwortlichkeiten wohin gehen, und danach die Herauslösung des Speicher- und Wiederherstellungsteils", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "de"}
{"prompt": "retry policy needs a per-route-class design rather than one global default, and the payments route needs fixing today regardless. give me the design, then turn retries off for the non-idempotent routes as the immediate step", "purpose": "planning", "secondary": "quickFix", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "courier API reference has to exist before the second partner fleet integrates, and while writing it please confirm whether location updates faster than 1 Hz are really dropped silently rather than rejected", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "plugin guide needs writing and i expect it will surface at least two behaviours we should change rather than document — the silent version mismatch being the obvious one. write the guide, and give me that list separately", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "escribe el documento de decisión sobre los límites de tasa y comprueba en el código qué descriptor gana realmente cuando varios coinciden, porque la documentación y el comportamiento no coinciden", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "on-call runbook for dispatch should be a page rather than folklore, and the redis restart that wipes every courier location deserves a guard rather than a warning. write the runbook, then add the confirmation prompt", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "elixir contexts need boundaries and the admin tool's :sys.replace_state call needs to stop existing. restructure the boundaries, and tell me what the admin tool actually needed that it couldn't get through a proper API", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "file references should resolve by content id before falling back to paths, which fixes cross-platform assemblies. make the change, and write the note for customers explaining why files saved before 4.0 still need the manual fix", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "mTLS added forty milliseconds at p50 and far more at p99, and the handshake count suggests we're not reusing connections at all. diagnose it properly, then fix the pooling configuration so we get the security without the latency", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "app shows stale order status for about a minute after delivery, which correlates with socket reconnects. confirm the mechanism, then change the reconnect path to reconcile against the current state rather than replaying from the client's last event", "purpose": "debugging", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "redis filled up on friday and dispatch stopped, because our eviction policy is noeviction and we mix ephemeral locations with state we can't lose. work out what's actually in there, then split the workloads so a location flood can't take dispatch down whatever you find, write it somewhere the next person will actually look.", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "modeller fails a government customer's accessibility review on seven counts including a viewport with no keyboard selection at all. work through them, and write the remediation plan with dates that we can actually send", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "flutter app stores auth tokens in three places and refreshes them in two", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "rename the `Assignment` struct in dispatch, it means something different in billing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "qt widgets subclass a base that reimplements half of QWidget's event handling", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain what happens to an accepted order when the restaurant closes afterwards", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "why does the courier app's location publisher stop when the screen locks", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "someone should check whether a partner can exceed their limit by spreading requests across endpoints", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that a plugin returning true from onCommand suppresses our own built-in command", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment le cache des restaurants est rafraîchi, et pourquoi toutes les cinq minutes ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/dispatch.md describes a two-stage assignment we replaced with scoring last year", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "header comments on IPlugin promise thread safety that the UI callbacks don't have", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer note about the minimum OS versions changing in 4.2", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "how should we shard dispatch when a city grows past what one zone process can handle", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test dispatch, where the failure mode is a courier standing outside a closed door", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether the modeller should move to a document format that supports partial loading", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "two partner fleets want to run their own dispatch and use us only for orders, what would that even mean", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "we need a plan for the modeller's plugin API now that four customers depend on undocumented behaviour", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to in-flight orders when we take a zone offline for a deploy", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns why a specific order was assigned to a specific courier, for support", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "location endpoint should reject rather than silently drop updates faster than 1 Hz", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "restaurant dashboard needs a late-order strip that survives being watched on a wall screen all day", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "assembly tree should virtualise, a 41-part assembly currently renders every node eagerly", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "route inspector needs to work when the control plane is down, from the last known config", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "whatever keeps dinner service running", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "next piece of the gateway work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "envoy filters reach us through static yaml, the control plane and one hand-edited bootstrap that predates both, which means the effective configuration is genuinely unknown. bring them onto one path, and produce the diff between what we thought was applied and what actually is i'm not attached to the current approach if there's an obviously better one.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like an honest read on whether our append-only order event log can be trusted as a source of truth, given that the admin tool updates rows directly to fix data, and the fix if it can't — including what to do about the rows already edited i'd rather have the reasoning written down than a quick answer.", "purpose": "review", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "assignments need an idempotency key so that a retried offer response can't produce a second assignment, but the key's scope depends on whether we treat an offer or an order as the unit. decide that with me, then implement the write path and the conflict response tell me if this is the wrong shape entirely, i won't be offended.", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "the flutter app keeps auth tokens in secure storage, in a provider and in a module-level variable, refreshing them in two of the three, which is why couriers occasionally get logged out mid-shift. consolidate onto one owner with a single refresh path, and make sure a refresh that fails while the app is backgrounded doesn't silently sign someone out", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "our health endpoint reports the dispatcher as healthy when its zone has no couriers connected at all, which is exactly the state we most need to page on, and it also stays green when redis is refusing writes. make it check what actually matters, keep it cheap enough for a two-second interval, and tell me which existing alerts become redundant", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "staging runs four upstreams and production runs forty-one behind identical connection pool and circuit breaker settings, which is why load-related failures never appear before release. bring the staging numbers into a sensible relationship with production, and note which settings are genuinely per-upstream rather than global so we don't scale the wrong ones", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "a city has grown past what one zone process can handle at dinner peak and the obvious answer is more zones, except that our zones are geographic and couriers cross them constantly. i'd like the options for sharding dispatch worked through — smaller zones with handoff, sharding by order rather than geography, or splitting the process differently — with the cross-zone courier case as the thing that decides it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "per-partner circuit breaking doesn't exist in our gateway, so one slow partner consumes the shared connection pool and everyone's requests queue behind theirs. add breakers scoped per partner with sensible defaults, expose the state so support can see who is tripped, and make sure a tripped breaker fails fast with a distinguishable status rather than a generic 503", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "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_51155'\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_51155'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDetermine why KeystoneBirchMigratorCoordinator produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"KeystoneSummitProxyCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Read projects/keystone/engine/render/atlas.cpp and tell me whether KeystoneDeltaCanvasService 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":"Lay out a two-milestone strategy for eliminating an empty state that flashes before cached data arrives in KeystoneLumenChartStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"// projects/keystone/ui/settings/PrivacyPane.tsx\nfinal class KeystoneFlintTimelineCoordinatorCoordinator {\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 KeystoneFlintTimelineCoordinator; 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":"KeystoneOspreyJobCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"KeystoneAsterWebhookCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"A flaky failure around KeystoneBasilRunnerService survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneBasilRunnerService\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":"planning","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"PM needs a concise migration note for KeystonePrismCacheStore, 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":"KeystoneDeltaCanvasCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about KeystoneBirchMigratorService, but the current prose in projects/keystone/app/src/main/SyncWorker.kt only describes the happy path. 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- keep public behavior and serialized data unchanged\n- stay compatible with the existing gRPC deployment\n- keep the work scoped to KeystoneBirchMigratorService and its direct tests\n\nSeveral teams work in this collaboration, C++, Next.js 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":"Move KeystoneAmberFilterService behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"UI ticket DES-51159: finish the compact KeystoneWillowCodecCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/keystone/cmd/exporter/main.py\nFramework: FastAPI\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 KeystoneWillowCodecCoordinator'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":"KeystoneBirchMigratorStore returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/keystone/apps/console/routes/usage.svelte and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Could KeystoneFernSnapshotService migrate incrementally?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"projects/keystone/pkg/cache/lease.rs has grown through several launches, and KeystoneEmberRelayService now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing Room deployment\n- keep the work scoped to KeystoneEmberRelayService and its direct tests\n\nSeveral teams work in this collaboration, C++, Next.js 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":"Two deliverables are holding up KeystoneMarbleTokenCoordinator. First, assess ownership and failure handling in projects/keystone/app/src/main/SyncWorker.kt. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/keystone/app/src/main/SyncWorker.kt, which follows gRPC conventions and currently suffers from out-of-order events after consumer rebalancing. Keep public behavior and serialized data unchanged.\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":"Stream KeystoneOrbitSyncService's audit events","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Extract KeystoneAcornWidgetService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Kestrel: # projects/keystone/workers/thumbnail/consumer.ex\n[worker.keystoneorbitsyncflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystoneorbitsyncflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystoneorbitsyncflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneOrbitSyncFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51121\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Make the one confirmed configuration correction in projects/keystone/workers/thumbnail/consumer.ex. 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":"Lumen: # projects/keystone/crates/index/src/segment.rs\n[worker.keystonecloudreconcilerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonecloudreconcilerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonecloudreconcilerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneCloudReconcilerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51138\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 KeystoneCloudReconcilerFlow'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":"Please resist widening this one: KeystoneKiteSchedulerService works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneKiteSchedulerService\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Before we approve KeystoneCopperBridgeService, assess whether a deadlock that appears only during shutdown is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"How does KeystoneCinderAuthStore propagate cancellation through the Room boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Walk through KeystoneMarbleTokenService's usage.svelte","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Sequence KeystoneJuniperCLIService's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Document KeystoneCoralUploadStore's cancellation rules","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Maple: Two asks around KeystoneQuartzPlayerCoordinator: (1) separate KeystoneQuartzPlayerCoordinator's policy from transport without behavior changes; (2) correct the known stale timeout beside it. Keep public behavior and serialized data unchanged, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Nimbus: The public surface of KeystoneFlintTimelineService is frozen, but its internal ownership in projects/keystone/workers/thumbnail/consumer.ex is difficult to test and even harder to change safely. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneFlintTimelineService\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for KeystoneKiteSchedulerCoordinator:\n- primary outcome: produce a consumer guide for KeystoneKiteSchedulerCoordinator\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/keystone/config/staging.toml\n- platform constraint: Room\n- known complication: a feature flag whose default differs between environments\n\nBoth results are required, but they should remain independently reviewable. Keep public behavior and serialized data unchanged; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Summarize the KeystoneBeaconStoreStore changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"For KeystoneAcornWidgetCoordinator, change KeystoneAcornWidgetCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, capture the contract and rollback note for consumers. Work from projects/keystone/apps/console/routes/usage.svelte, stay with gRPC, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"KeystoneOpalRouterCoordinator: sort out the rough edge","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Lay out a two-milestone strategy for eliminating a deadlock that appears only during shutdown in KeystoneRainfallDBStore, with risk checks and a crisp definition of done for each milestone.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"KeystoneBeaconStoreCoordinator: diagnose, then correct","purpose":"debugging","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Sketch the KeystoneLedgerGateService migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Opal: # projects/keystone/internal/auth/refresh.go\n[worker.keystonepinemetricsflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonepinemetricsflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonepinemetricsflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystonePineMetricsFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51132\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 KeystonePineMetricsFlow'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":"Prism: projects/keystone/apps/console/routes/usage.svelte 里的 KeystoneHarborIndexService 最近在 gRPC 流程中出现间歇性问题。 原因已经明确：只把 staging timeout 从 15 秒改成 30 秒，并调整对应 assertion。\n\n约束：\n- 继续使用 gRPC\n- 保持兼容性和取消语义\n- 改动只限于 KeystoneHarborIndexService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"zh"}
{"prompt":"What is the safest way to split projects/keystone/web/components/FilterDrawer.vue into independently owned modules while KeystoneGarnetModalService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"Milestones for replacing KeystoneAtlasSearchStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"KeystoneIrisBatchCoordinator: polish, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Ticket OPS-51120: retire the legacy replay path for KeystoneAmberFilterFlow\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 KeystoneAmberFilterFlow, 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":"For KeystoneSlateEditorCoordinator, produce a consumer guide for KeystoneSlateEditorCoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/keystone/crates/index/src/segment.rs, stay with Room, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Sketch the KeystoneVelaDrawerService migration","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Add a bounded KeystoneRavenSessionStore export stream that resumes from checkpoints, respects cancellation, and exposes queue lag plus terminal failure counters.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-51143: finish the compact KeystoneOspreyJobFlow filter experience\n\nRoute: /catalog/search\nSource: projects/keystone/config/staging.toml\nFramework: Room\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible KeystoneOspreyJobFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Before touching projects/keystone/Sources/CLI/Commands/Doctor.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":"Ticket OPS-51110: retire the legacy replay path for KeystoneEchoRegistryFlow\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 KeystoneEchoRegistryFlow 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":"Animate the KeystoneCedarPolicyService drawer","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"KeystoneFrostPanelCoordinator needs a paired pass: assess ownership and failure handling in projects/keystone/services/ledger/replay.go, plus capture the contract and rollback note for consumers. Use projects/keystone/services/ledger/replay.go as the source of truth, preserve the Swift 6 contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Memory attributed to KeystoneCopperBridgeStore 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":"Incident timeline — INC-51131\n\n08:02 deploy KeystoneJuniperCLIFlow 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 KeystoneJuniperCLIFlow 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":"Quartz: // projects/keystone/internal/auth/refresh.go\nfinal class KeystoneMapleQueueFlowCoordinator {\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 KeystoneMapleQueueFlow; 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":"KeystoneCoralUploadCoordinator: restructure, then correct","purpose":"refactor","secondary":"backendImpl","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Security flagged KeystoneKiteSchedulerStore for a read-only pass because its Room boundary mixes tenant data, retries, and cancellation in subtle ways. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current Room operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"KeystoneAtlasSearchService leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Split projects/keystone/cmd/exporter/main.py by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Is KeystoneAmberFilterStore safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"KeystoneMoonlitSDKCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"# projects/keystone/internal/auth/refresh.go\n[worker.keystonemicaprofilecoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonemicaprofilecoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonemicaprofilecoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneMicaProfileCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51152\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/keystone/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":"Raven: Ticket OPS-51116: retire the legacy replay path for KeystoneSummitProxyFlow\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 KeystoneSummitProxyFlow 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":"KeystoneWillowCodecFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/keystone/ml/pipeline/features.py and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"On compact widths, KeystoneMicaProfileStore's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Sable: Ticket OPS-51156: retire the legacy replay path for KeystoneSpruceDaemonCoordinator\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\nWire KeystoneSpruceDaemonCoordinator's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"One contained cleanup in projects/keystone/workers/thumbnail/consumer.ex: remove the obsolete KeystoneOpalRouterService import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-51135: finish the compact KeystoneHarborIndexFlow filter experience\n\nRoute: /catalog/search\nSource: projects/keystone/apps/console/routes/usage.svelte\nFramework: gRPC\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 KeystoneHarborIndexFlow'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":"Move KeystoneGarnetModalStore's clock and ID generation behind the existing environment type so tests no longer reach global state; outputs and scheduling order must stay identical. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/keystone/engine/render/atlas.cpp b/projects/keystone/engine/render/atlas.cpp\nindex 62d71aa..90f3c1e 100644\n--- a/projects/keystone/engine/render/atlas.cpp\n+++ b/projects/keystone/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\nRestructure KeystoneDeltaCanvasFlow 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":"The behavior of KeystoneWillowCodecService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/keystone/ml/pipeline/features.py. 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- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current FastAPI operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Bring KeystoneFlintTimelineStore'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":"The destination for KeystoneLumenChartService is broadly agreed; the missing piece is a reversible route from projects/keystone/Sources/CLI/Commands/Doctor.swift to that target. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneLumenChartService\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"KeystoneCopperBridgeCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"KeystoneSableParserCoordinator: handle the lingering thing","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Tide: The destination for KeystoneEmberRelayStore is broadly agreed; the missing piece is a reversible route from projects/keystone/crates/index/src/segment.rs to that target. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneEmberRelayStore\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Two asks around KeystonePineMetricsCoordinator: (1) finish KeystonePineMetricsCoordinator's responsive empty and retry states; (2) capture the contract and rollback note for consumers. Keep public behavior and serialized data unchanged, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Test Suite 'KeystoneMoonlitSDKFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[KeystoneMoonlitSDKFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/keystone/pkg/cache/lease.rs:144: error: -[KeystoneMoonlitSDKFlowTests 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 '-[KeystoneMoonlitSDKFlowTests 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\nBring KeystoneMoonlitSDKFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Documente le contrat KeystoneFrostPanelStore","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"fr"}
{"prompt":"What sequence would let KeystoneSableParserService adopt gRPC with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Walk through KeystoneFernSnapshotStore's main.py","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Does KeystoneQuartzPlayerService preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Teach KeystoneCinderAuthFlow to verify signed continuation tokens, reject cross-tenant cursors, and rotate keys without invalidating tokens issued during the overlap window.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Memory attributed to KeystoneLumenChartFlow 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":"// projects/keystone/web/components/FilterDrawer.vue\nfinal class KeystoneFrostPanelFlowCoordinator {\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 KeystoneFrostPanelFlow 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":"Three teams extended KeystoneEchoRegistryStore independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current gRPC operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.\n\nThe individual edits look tiny, but the semantic cleanup spans the repository and must preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Three teams extended KeystoneSpruceDaemonService independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current OpenTelemetry operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"KeystoneRainfallDBService's staging timeout is already known to be wrong: change the single projects/keystone/Sources/App/SessionStore.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":"KeystoneSlateEditorService flakes under UTC","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"2026-07-30T08:14:11.409Z level=info service=keystonemosaicgridflow pod=keystonemosaicgridflow-7cf8 request_id=51117 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=keystonemosaicgridflow request_id=51117 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=keystonemosaicgridflow request_id=51117 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=keystonemosaicgridflow request_id=51117 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=keystonemosaicgridflow request_id=51117 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=keystonemosaicgridflow request_id=51117 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=keystonemosaicgridflow request_id=51117 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=keystonemosaicgridflow request_id=51117 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 KeystoneMosaicGridFlow 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":"KeystoneNovaPickerCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-51119\n\n08:02 deploy KeystoneIrisBatchFlow 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 KeystoneIrisBatchFlow 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":"Umbra: // projects/keystone/ui/settings/PrivacyPane.tsx\nfinal class KeystoneDriftConsoleFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate KeystoneDriftConsoleFlow'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":"Zentriere das KeystoneIrisBatchStore-Modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"de"}
{"prompt":"KeystonePrismCacheCoordinator: give it a nicer flow","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Vela: # projects/keystone/services/ledger/replay.go\n[worker.keystonebasilrunnercoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonebasilrunnercoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonebasilrunnercoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneBasilRunnerCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51157\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/keystone/services/ledger/replay.go. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"Willow: # projects/keystone/app/src/main/SyncWorker.kt\n[worker.keystoneacornwidgetflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystoneacornwidgetflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystoneacornwidgetflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneAcornWidgetFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51125\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/keystone/app/src/main/SyncWorker.kt and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"KeystoneAtlasSearchCoordinator: diagnose, then assess","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Fresh release brief for KeystoneEchoRegistryCoordinator:\n- primary outcome: separate KeystoneEchoRegistryCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/keystone/src/sync/reconcile.ts\n- platform constraint: gRPC\n- known complication: a misleading timeout name used in five packages\n\nBoth results are required, but they should remain independently reviewable. Keep public behavior and serialized data unchanged; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"UI ticket DES-51149: finish the compact KeystoneNimbusFormFlow filter experience\n\nRoute: /catalog/search\nSource: projects/keystone/ml/pipeline/features.py\nFramework: FastAPI\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible KeystoneNimbusFormFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"How does KeystoneSableParserStore propagate cancellation through the gRPC boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Two asks around KeystoneFernSnapshotCoordinator: (1) find the unknown cause of a feature flag whose default differs between environments; (2) capture the contract and rollback note for consumers. Keep public behavior and serialized data unchanged, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"A flaky failure around KeystoneVelaDrawerStore survived three attempted fixes, so I want the evidence and invariants traced before another patch lands. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneVelaDrawerStore\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Add a bounded KeystoneCloudReconcilerService 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":"Ownership of KeystoneRavenSessionService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current gRPC operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Support wants the behavior in projects/keystone/ml/pipeline/features.py recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Style KeystonePineMetricsStore's offline state","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Documente o contrato de KeystoneFrostPanelService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"Ticket OPS-51154: retire the legacy replay path for KeystoneLumenChartCoordinator\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 KeystoneLumenChartCoordinator behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Xylem: UI ticket DES-51133: finish the compact KeystoneCedarPolicyFlow filter experience\n\nRoute: /catalog/search\nSource: projects/keystone/packages/api/openapi.yaml\nFramework: Room\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\nBring KeystoneCedarPolicyFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"KeystoneNovaPickerStore has four wrappers that only translate the same error enum. Collapse them into one adapter and preserve every public case, message, and metric label. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"KeystoneCedarPolicyCoordinator needs a paired pass: separate KeystoneCedarPolicyCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/keystone/config/staging.toml as the source of truth, preserve the Room contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Center the KeystoneSlateEditorStore modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"Yarrow: UI ticket DES-51141: finish the compact KeystoneOpalRouterFlow filter experience\n\nRoute: /catalog/search\nSource: projects/keystone/workers/thumbnail/consumer.ex\nFramework: OpenTelemetry\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 KeystoneOpalRouterFlow'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":"KeystoneSpruceDaemonFlow needs an idempotent replay endpoint backed by OpenTelemetry; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Could the reasoning behind KeystoneTideWorkerStore's gRPC choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"KeystoneOrbitSyncCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"KeystoneNimbusFormCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"KeystoneOrbitSyncStore's PrivacyPane.tsx needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"// projects/keystone/lib/codec/frame.cc\nfinal class KeystoneCopperBridgeFlowCoordinator {\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 KeystoneCopperBridgeFlow; 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":"Security flagged KeystoneSummitProxyStore for a read-only pass because its OpenTelemetry boundary mixes tenant data, retries, and cancellation in subtle ways. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current OpenTelemetry operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-51118: retire the legacy replay path for KeystoneAtlasSearchFlow\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 KeystoneAtlasSearchFlow 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":"Introduce a durable deduplication key for KeystoneNovaPickerService events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"KeystoneCoralUploadService's staging.toml needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"The KeystoneMicaProfileFlow 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":"Match KeystoneLedgerGateStore's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/keystone/Sources/CLI/Commands/Doctor.swift b/projects/keystone/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/keystone/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/keystone/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 KeystonePrismCacheFlow'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":"KeystoneRavenSessionFlow's staging timeout is already known to be wrong: change the single projects/keystone/src/sync/reconcile.ts value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"KeystoneHarborIndexCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"PM needs a concise migration note for KeystoneTideWorkerService, 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":"KeystoneLedgerGateCoordinator needs a paired pass: separate KeystoneLedgerGateCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/keystone/src/sync/reconcile.ts as the source of truth, preserve the gRPC contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"In projects/keystone/ui/settings/PrivacyPane.tsx hat KeystoneDriftConsoleService ein sporadisches Problem im OpenTelemetry-Ablauf. Die Ursache ist klar: Ändere nur das Staging-Timeout von 15 auf 30 Sekunden und passe die Assertion an.\n\nRandbedingungen:\n- OpenTelemetry weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf KeystoneDriftConsoleService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um KeystoneDriftConsoleService mit OpenTelemetry kompatibel.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"de"}
{"prompt":"The data is already available in projects/keystone/lib/codec/frame.cc; 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":"Zephyr: # projects/keystone/src/sync/reconcile.ts\n[worker.keystonetideworkerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonetideworkerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonetideworkerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneTideWorkerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51140\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/keystone/src/sync/reconcile.ts and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Checkout: The KeystoneEmberRelayFlow 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":"KeystoneAmberFilterCoordinator: restructure, then correct","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Is KeystoneBeaconStoreService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"For KeystoneJuniperCLICoordinator, produce a consumer guide for KeystoneJuniperCLICoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/keystone/workers/thumbnail/consumer.ex, stay with OpenTelemetry, and keep public behavior and serialized data unchanged. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"En projects/keystone/workers/thumbnail/consumer.ex, KeystoneDriftConsoleStore tiene un problema intermitente en el flujo de OpenTelemetry. Sigue queue, scheduler y cancelación, compara hipótesis y encuentra la causa antes de proponer cambios.\n\nRestricciones:\n- seguir con OpenTelemetry\n- conservar compatibilidad y cancelación\n- limitar el cambio a KeystoneDriftConsoleStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con OpenTelemetry alrededor de KeystoneDriftConsoleStore.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"es"}
{"prompt":"projects/keystone/packages/api/openapi.yaml 里的 KeystoneOspreyJobStore 最近在 Room 流程中出现间歇性问题。 请拆分职责并去掉重复，同时保持 API、wire value、顺序和可观察行为不变。\n\n约束：\n- 继续使用 Room\n- 保持兼容性和取消语义\n- 改动只限于 KeystoneOspreyJobStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Where did KeystoneCedarPolicyStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Pin KeystoneMosaicGridService's Swift dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-51115\n\n08:02 deploy KeystoneMarbleTokenFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFind the source of this KeystoneMarbleTokenFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Split projects/keystone/web/components/FilterDrawer.vue by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/keystone/packages/api/openapi.yaml: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: keystonecinderauthcoordinator::scheduler::LeaseTask::flush\n at ./projects/keystone/packages/api/openapi.yaml:217:18\n 4: keystonecinderauthcoordinator::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\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Reconstruct the KeystoneCinderAuthCoordinator 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":"Exporter: # projects/keystone/Sources/CLI/Commands/Doctor.swift\n[worker.keystonewrenexportflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonewrenexportflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonewrenexportflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneWrenExportFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51124\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/keystone/Sources/CLI/Commands/Doctor.swift. 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":"Does KeystoneMoonlitSDKStore 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":"Scheduler: // projects/keystone/cmd/exporter/main.py\nfinal class KeystoneCraneWorkspaceFlowCoordinator {\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 KeystoneCraneWorkspaceFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Dashboard: projects/keystone/infra/modules/edge/main.tf has grown through several launches, and KeystoneMapleQueueStore now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to KeystoneMapleQueueStore and its direct tests\n\nSeveral teams work in this collaboration, C++, Next.js monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe individual edits look tiny, but the semantic cleanup spans the repository and must preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/keystone/crates/index/src/segment.rs b/projects/keystone/crates/index/src/segment.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/keystone/crates/index/src/segment.rs\n+++ b/projects/keystone/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\nRestructure KeystoneEmberRelayCoordinator so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Worker: diff --git a/projects/keystone/pkg/cache/lease.rs b/projects/keystone/pkg/cache/lease.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/keystone/pkg/cache/lease.rs\n+++ b/projects/keystone/pkg/cache/lease.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\nRestructure KeystoneSlateEditorFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Introduce a durable deduplication key for KeystoneDeltaCanvasStore events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Simulator: The KeystoneBasilRunnerFlow empty state in projects/keystone/web/components/FilterDrawer.vue needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up KeystoneMapleQueueCoordinator. First, produce a consumer guide for KeystoneMapleQueueCoordinator. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/keystone/infra/modules/edge/main.tf, which follows Swift 6 conventions and currently suffers from cancellation being swallowed at the repository boundary. Keep public behavior and serialized data unchanged.\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":"writing","secondary":"quickFix","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"PM needs a concise migration note for KeystoneCloudReconcilerStore, 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":"We expect KeystoneWillowCodecStore to outgrow its current FastAPI arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing FastAPI deployment\n- keep the work scoped to KeystoneWillowCodecStore and its direct tests\n\nSeveral teams work in this collaboration, C++, Next.js monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Check KeystonePineMetricsService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"KeystoneTideWorkerCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-51123\n\n08:02 deploy KeystoneCoralUploadFlow 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 KeystoneCoralUploadFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-51126: retire the legacy replay path for KeystoneQuartzPlayerFlow\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 KeystoneQuartzPlayerFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"KeystoneGarnetModalCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Runbook: Ticket OPS-51114: retire the legacy replay path for KeystoneVelaDrawerFlow\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 KeystoneVelaDrawerFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Compare the old and new KeystoneCraneWorkspaceService adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"How should KeystoneSummitProxyService be decomposed?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Give KeystoneAsterWebhookService's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"KeystoneRainfallDBCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Trace: Incident timeline — INC-51113\n\n08:02 deploy KeystoneKiteSchedulerFlow 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. Turn the material above into a concise KeystoneKiteSchedulerFlow 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":"Test Suite 'KeystoneRainfallDBFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[KeystoneRainfallDBFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/keystone/Sources/App/SessionStore.swift:144: error: -[KeystoneRainfallDBFlowTests 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 '-[KeystoneRainfallDBFlowTests 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\nFinish the visible KeystoneRainfallDBFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Profiler: PM is preparing the KeystoneEchoRegistryService rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneEchoRegistryService\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Assess the KeystoneAcornWidgetStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"projects/keystone/workers/thumbnail/consumer.ex の KeystoneFlintTimelineFlow で、OpenTelemetry の flow に断続的な問題が起きています。 原因は判明済みです。staging timeout だけを 15 秒から 30 秒へ変え、対応する assertion を直してください。\n\n制約:\n- OpenTelemetry を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は KeystoneFlintTimelineFlow のみ","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"ja"}
{"prompt":"Console: diff --git a/projects/keystone/db/migrations/20260730_events.sql b/projects/keystone/db/migrations/20260730_events.sql\nindex 62d71aa..90f3c1e 100644\n--- a/projects/keystone/db/migrations/20260730_events.sql\n+++ b/projects/keystone/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 KeystoneLedgerGateFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"How does KeystoneCraneWorkspaceStore propagate cancellation through the FastAPI boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Workspace: // projects/keystone/app/src/main/SyncWorker.kt\nfinal class KeystoneSableParserFlowCoordinator {\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，并明确说明证据和取舍。 Split KeystoneSableParserFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"The KeystoneMoonlitSDKService 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":"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_51122'\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_51122'::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 KeystoneBeaconStoreFlow 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":"KeystoneWrenExportCoordinator needs a paired pass: assess ownership and failure handling in projects/keystone/Sources/App/SessionStore.swift, plus capture the contract and rollback note for consumers. Use projects/keystone/Sources/App/SessionStore.swift as the source of truth, preserve the FastAPI contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"En projects/keystone/config/staging.toml, KeystoneCinderAuthService tiene un problema intermitente en el flujo de Room. Redacta una guía para consumidores con contrato, errores, retry y un ejemplo copiable; no cambies el handler.\n\nRestricciones:\n- seguir con Room\n- conservar compatibilidad y cancelación\n- limitar el cambio a KeystoneCinderAuthService Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con Room alrededor de KeystoneCinderAuthService.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"es"}
{"prompt":"Repository: # projects/keystone/ml/pipeline/features.py\n[worker.keystonefernsnapshotflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.keystonefernsnapshotflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.keystonefernsnapshotflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.KeystoneFernSnapshotFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-51129\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. Align KeystoneFernSnapshotFlow'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":"Pipeline: Incident timeline — INC-51137\n\n08:02 deploy KeystoneAsterWebhookFlow 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. Turn the material above into a concise KeystoneAsterWebhookFlow 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.4,"slice":"pasted-context","lang":"en"}
{"prompt":"KeystoneDriftConsoleCoordinator is blocking the next release because stale cursors when a page is resumed. I need two concrete outcomes from a single pass: change KeystoneDriftConsoleCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing OpenTelemetry conventions in projects/keystone/workers/thumbnail/consumer.ex; keep public behavior and serialized data unchanged. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Gateway: The behavior of KeystoneMapleQueueService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/keystone/internal/auth/refresh.go. 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- touch generated artifacts only through their checked-in generator\n- keep public behavior and serialized data unchanged\n- retain the current Swift 6 operational envelope\n\nThe relevant code crosses collaboration, C++, Next.js. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: KeystoneMarbleTokenStore has one known configuration mistake in projects/keystone/app/src/main/SyncWorker.kt, not an open-ended failure investigation. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing gRPC deployment\n- keep the work scoped to KeystoneMarbleTokenStore and its direct tests\n\nSeveral teams work in this collaboration, C++, Next.js monorepo, so keep ownership and handoff points understandable in a small review.\n\nThe cause and exact value change are already known, so keep this as a contained correction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Renderer: Incident timeline — INC-51150\n\n08:02 deploy KeystoneRavenSessionCoordinator 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\nReconstruct the KeystoneRavenSessionCoordinator 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":"Does KeystoneWrenExportStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Pin KeystoneJuniperCLIStore's OpenTelemetry dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Give KeystoneOpalRouterStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Em projects/keystone/app/src/main/SyncWorker.kt, o KeystoneHarborIndexStore tem um problema intermitente no fluxo de gRPC. Leia o fluxo atual e avalie ownership, cancelamento e ordem; preciso apenas da análise.\n\nRestrições:\n- continuar com gRPC\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao KeystoneHarborIndexStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"Split projects/keystone/app/src/main/SyncWorker.kt by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched. Although each edit is small, the semantic rename spans the whole repository.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Check KeystoneWrenExportService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"// projects/keystone/web/components/FilterDrawer.vue\nfinal class KeystoneGarnetModalFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate KeystoneGarnetModalFlow'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":"Translate the KeystoneQuartzPlayerStore setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current KeystoneMosaicGridStore design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside KeystoneMosaicGridStore\n- keep public behavior and serialized data unchanged\n\nThis repository spans collaboration, C++, Next.js; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"KeystoneCloudReconcilerCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-51142: retire the legacy replay path for KeystoneNovaPickerFlow\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 KeystoneNovaPickerFlow 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":"What sequence would let KeystoneBasilRunnerStore adopt Swift 6 with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"We expect KeystoneMicaProfileService to outgrow its current Swift 6 arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- keep public behavior and serialized data unchanged\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to KeystoneMicaProfileService and its direct tests\n\nSeveral teams work in this collaboration, C++, Next.js monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"KeystoneVelaDrawerCoordinator is blocking the next release because a deadlock that appears only during shutdown. I need two concrete outcomes from a single pass: change KeystoneVelaDrawerCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing FastAPI conventions in projects/keystone/Sources/CLI/Commands/Doctor.swift; keep public behavior and serialized data unchanged. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Centre la modale KeystoneIrisBatchService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"fr"}
{"prompt":"KeystoneCraneWorkspaceCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Indexer: projects/keystone/config/staging.toml の KeystoneOspreyJobService で、Room の flow に断続的な問題が起きています。 段階、互換性、metrics、rollback、ownership を提案し、コード変更の前で止めてください。\n\n制約:\n- Room を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は KeystoneOspreyJobService のみ","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"ja"}
{"prompt":"KeystoneMosaicGridCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
data/round2-12.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "our shared-space colocation, which drifts between headsets. is the approach sound or do we need something else?\n\n1. host creates a cloud anchor at session start and shares its id\n2. each client resolves the anchor once and stores the resulting pose\n3. all shared content is positioned relative to that stored pose\n4. each client's own tracking updates are applied on top of it\n5. there is no periodic re-resolution and no drift correction between clients\n6. relocalisation after tracking loss re-anchors to the client's own map, not the shared one\n\nusers stand around a physical table and expect virtual objects to stay on it for everyone", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "the same value-date logic exists in four places with three different answers:\n\n// ValueDate.java\nreturn postedAt.atZone(ZoneOffset.UTC).toLocalDate();\n\n// settlement/BatchRunner.java\nreturn LocalDate.ofInstant(postedAt, ZoneId.of(centre.timezone()));\n\n// reconciliation/Matcher.java\nreturn postedAt.atZone(ZoneId.of(\"Europe/Madrid\")).toLocalDate(); // hardcoded, one centre\n\n-- reports/daily_postings.sql\nDATE(posted_at AT TIME ZONE 'UTC')\n\nthe core banking system uses the booking centre's local date with a 23:00 cutover, which none of these implements", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "mail delivery policy — concurrency, backoff, deferral limits — is inline in the SMTP worker, which is why one destination can starve every worker. extract it into something testable and configurable per destination, keeping today's behaviour as the default so we can change it deliberately rather than accidentally i'm not attached to the current approach if there's an obviously better one.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "statement footer still says 2025", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "our transactional email API, used by six internal teams, documented in a wiki page from 2023:\n\nPOST /v1/send\n body: { to, from, subject, template_id, variables, headers?, send_at?, pool? }\n pool defaults to \"transactional\"; the other pools are \"marketing\" and \"bulk\", and choosing wrong affects deliverability for everyone\n send_at more than 7 days out is silently clamped to 7 days\n a template variable that is missing renders as an empty string rather than failing\n suppression list is checked at send time, not at enqueue time, so a scheduled send may be suppressed later\n the response is 202 with a message id; delivery status arrives on a webhook or via GET /v1/messages/{id}\n rate limits are per pool per hour and are not published anywhere\n\nwrite the reference; the pool choice and the silent variable behaviour are what teams get wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "the tinting code creates a material instance per object, which is our entire draw-call problem:\n\nvoid OnHoverEnter(GameObject go) {\n var r = go.GetComponent<Renderer>();\n r.material.color = hoverColor; // instantiates the material\n}\n\nvoid OnHoverExit(GameObject go) {\n var r = go.GetComponent<Renderer>();\n r.material.color = originalColor; // and again\n}\n\nvoid Place(GameObject prefab, Pose pose) {\n var go = Instantiate(prefab, pose.position, pose.rotation);\n go.GetComponent<Renderer>().material.SetFloat(\"_Metallic\", 0.2f); // and again\n}\n\nsame visual result required, but batching has to survive", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "mail operations console is a grafana dashboard and a terminal, which is why incidents take longer than they should. build the deliverability view to the spec, including the verbatim SMTP responses per destination, and make it usable on a phone because that's where it gets opened context if it helps: this has been open since before i joined the team.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "a customer's statement shows a transaction twice and support can't explain it:\n\nledger entries for account 4471, 2026-07-28:\n entry 881204 DEBIT 120.00 ref=CARD-9021 posted_at=14:02:14 source=card_network\n entry 881207 DEBIT 120.00 ref=CARD-9021 posted_at=14:02:19 source=card_network\n entry 881209 CREDIT 120.00 ref=CARD-9021 posted_at=14:31:02 source=reversal\n\nthe card network sent the authorisation twice with the same reference, five seconds apart, and our idempotency check is on (ref, amount, posted_date) with posted_date derived from posted_at in local time", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "one value-date implementation, four callers", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "what makes a posting a duplicate?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "statement rendering exists three times — PDF, HTML and CSV — each computing the running balance independently and one of them rounding negatives differently. consolidate onto one renderer with format-specific output, with the PDF as the reference because it's the regulated artefact, and diff a month of statements to prove nothing moved whatever you find, write it somewhere the next person will actually look.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "batch fetch size down to 5000", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "instructor panel should follow on a tether", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "settlement thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "ledger team loses two engineers in september and the code they own includes the settlement batch, the value-date logic and the core banking adapter. i'd like a plan for that departure specifically: what has to be written down, what should be simplified before they go, and what we accept will slow down afterwards", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "i'd like an honest read of whether our DKIM alignment is strict enough to reject mail from the old selector, and if it is, the fix — ideally without unpublishing a key that some senders still use", "purpose": "review", "secondary": "quickFix", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "AR content is authored by instructors in unity and shipped in the app binary, which is a release per lesson", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "one money type across the ledger", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "a customer's statement shows the same card transaction twice for half an hour before a reversal nets it out, and our idempotency check apparently didn't catch a repeat five seconds apart. work out exactly which part of the check let it through before we change anything, because the fix depends on whether it was the reference or the date", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "what does the core banking system do with a message we resend after a timeout", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "hand tracking loses the pinch gesture after a few minutes and only on device:\n\n[XR] Hand tracking subsystem started, confidence high\n[XR] Frame 41882: left hand lost (confidence low), reacquired in 3 frames\n[App] PinchDetector: state=Open → Pinching (thumb-index 0.018m)\n[App] PinchDetector: state=Pinching → Open (thumb-index 0.031m)\n[App] PinchDetector: state=Open → Pinching (thumb-index 0.019m)\n[XR] Frame 88214: hand joints returning stale poses (timestamp unchanged for 12 frames)\n[App] PinchDetector: no state change for 40 seconds\n\nthe detector caches the last joint poses and compares against them, so stale poses look like a perfectly steady hand", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "deliverability to one provider collapsed and their postmaster tools show this:\n\nspam rate: 0.02% → 0.41% (threshold 0.30%)\ndomain reputation: high → low\nauthenticated traffic: 100%\nencrypted traffic: 100%\nIP reputation: high\ntop feedback loop complaints: \"password reset\" 88%, \"transaction alert\" 9%\n\nwe started sending password reset emails from the same domain and IP pool as marketing three weeks ago\n\nour own numbers for the same period:\n transactional volume: 1.2M/day (unchanged)\n marketing volume: 0 → 900k/day (campaign started three weeks ago)\n password reset volume: 41k/day (moved onto this pool three weeks ago)\n unsubscribe rate on marketing: 2.1%\n bounce rate overall: 0.4% → 1.9%\n\nsending IPs: 4, shared across all three streams, no subdomain separation, one DKIM selector for everything", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the AR app's 3.1 release:\n\n41c9e0b fix(hands): pinch detection now ignores stale joint poses\n88f21c0 feat(colocation): shared anchors re-resolve every 30 seconds with drift correction\nc0aa774 perf(render): objects share materials via property blocks, draw calls down from 1,482 to 210\n2e91b45 fix(anchors): relocalisation re-anchors to the shared map rather than the local one\naa30f19 feat(ui): hand menu can be summoned with either hand\n9c1d004 chore: minimum OS is now visionOS 2.2 and Android XR 1.1\n4410bb7 fix(audio): spatial audio no longer resets on app resume\nb77e910 feat(session): a session survives a headset being removed for up to 5 minutes\n\nour users are enterprise training teams; two of these change behaviour their instructors have built lessons around", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "design spec for the AR training session's instructor panel, unity:\n\nInstructor panel (world-anchored, 0.6m wide, follows on a lazy tether)\n- Participant list: name, headset battery, tracking quality, current step. Rows 6cm tall, readable at 1.5m.\n- Tracking quality uses shape as well as colour — a filled, half or empty ring — because instructors are often colour-blind and always in a hurry.\n- Step control: previous / next / jump, with a confirmation for jump because it moves everyone.\n- A \"recentre everyone\" action that re-resolves the shared anchor and reports which headsets succeeded.\n- Alerts appear as a strip along the top: a participant losing tracking for more than 5 seconds, or falling behind by more than one step.\n- The panel must be summonable from either hand and dismissible with a glance away for 3 seconds.\n- Text must remain legible while the instructor is walking, which means no thin weights and no animation on the numbers.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "per-destination concurrency cap of 8", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "queue age histogram on the console", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "delivery policy out of the SMTP code", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "javadoc for the posting idempotency rule", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "is the pinch threshold distance-dependent?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "why do anchors drift between headsets?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "accruals are a cent out mid-month", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "email reputation has to recover before the statement run or a million statements land in spam, and the underlying cause is that transactional, notification and marketing mail share a domain and an IP pool. work through the separation options with the warm-up period as the awkward part, and tell me what we do about the statement run that falls in the middle of it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "AnchorManager has grown to own resolution, tracking, persistence, relocalisation and debug drawing, and it's the class the drift fix has to touch. before anyone starts i'd like agreement on the split — what the pieces are, which one the fix lives in, and whether we do the split first or the fix first given the demo date", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "an auditor has asked six questions about idempotency, partial batches, adjustments, value dates, reconciliation and retention, and several of our honest answers are uncomfortable. write the controls document from the code and the runbooks, and mark clearly the ones we cannot currently substantiate rather than writing something defensible-sounding we've been burned by guessing at this before, so evidence over instinct please.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "internal hand-tracking guide doesn't exist, and every developer rediscovers that TryGetJoint returns stale poses instead of failing. write the guide for internal developers covering the API's real behaviour, the confidence values nobody checks, and the frame-rate dependence of our thresholds keep it concrete — file names and line numbers are more use than principles here.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether our batch can commit half a transfer — the debit without the credit — given that it commits every thousand records with postings in file order rather than by transfer. read the runner and the input generation together and tell me whether that's possible, and whether it happened on the twenty-ninth", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "we have three ways to schedule work in the ledger service: quartz, a database poller and a cron container", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "suppression list is checked at send time, so a scheduled statement can go to an unsubscribed address", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "instructor panel", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "settlement batch can leave a partial day applied and our recovery is a script someone writes at four in the morning, which the operational risk register has now noticed. i'd like the options for making it restartable worked through — a checkpoint table, record-level idempotency, or regenerating a stable input file — with the month-end runtime and the eight o'clock cutover as the constraints that actually decide it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand what happens to an anchor when a headset relocalises after tracking loss", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "batch needs a checkpoint table so a failed run can resume rather than being reconstructed by hand", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "AR app carries two input abstractions, ours and the XR toolkit's, and new code picks whichever the author saw first. move everything onto the toolkit's, and confirm whether our own layer is doing anything the toolkit doesn't before we delete it tell me if this is the wrong shape entirely, i won't be offended.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "ledger entries table has an updated_at column that three jobs quietly set, on a table that is supposed to be immutable. stop the writes, and tell me whether any of those three jobs was relying on it for something we'd miss nobody has trusted this code for about a year, which is part of the problem.", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "overnight settlement aborted and left the batch half-applied, which has never happened before:\n\nSEVERE [batch-worker-3] com.lumenbank.settlement.BatchRunner - batch SETTLE-20260729 failed at record 41882 of 88214\njava.sql.BatchUpdateException: ORA-00060: deadlock detected while waiting for resource\n\tat oracle.jdbc.driver.OraclePreparedStatement.executeLargeBatch(OraclePreparedStatement.java:10032)\n\tat com.lumenbank.settlement.PostingDao.applyBatch(PostingDao.java:212)\n\tat com.lumenbank.settlement.BatchRunner.run(BatchRunner.java:88)\nWARNING [batch-worker-3] rollback failed: connection closed\nSEVERE [batch-worker-3] batch marked FAILED, 41,881 postings committed, 46,333 not applied\n\nthe runner commits every 1,000 records and has no restart-from-checkpoint path", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "so the headset drops to 45fps whenever a user looks at the assembly area:\n\nUnity Profiler (Quest 3, 10s):\n PlayerLoop 22.1ms\n Camera.Render 14.8ms\n Drawing (opaque) 9.2ms batches: 1,482 setpass: 412\n Shadows 3.1ms\n Update.ScriptRunBehaviourUpdate 4.2ms\n AnchorManager.Update 2.9ms (GC.Alloc 812 KB)\n PostLateUpdate.UpdateAllRenderers 1.8ms\n\nWarning: 412 SetPass calls, target is under 80\nWarning: 1,482 draw calls, dynamic batching disabled by per-object material instances\n\nevery placed object gets a material instance so we can tint it on hover", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "outbound mail to one large provider started bouncing this morning:\n\n2026-07-29T09:02:14Z smtp-out[41221]: connecting to mx1.provider.example:25\n2026-07-29T09:02:14Z smtp-out[41221]: 220 mx1.provider.example ESMTP\n2026-07-29T09:02:15Z smtp-out[41221]: 250-STARTTLS\n2026-07-29T09:02:15Z smtp-out[41221]: TLS established, TLS1.3, X25519\n2026-07-29T09:02:15Z smtp-out[41221]: 550 5.7.1 Unauthenticated email from lumen.io is not accepted due to domain's DMARC policy\n2026-07-29T09:02:15Z smtp-out[41221]: message 8f2b1c40 bounced, queue removed\n\nour DMARC is p=reject, SPF passes, and DKIM signing was moved to a new key on monday", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "interest accruals are a few cents out for accounts opened mid-month, here's one:\n\naccount 4471, opened 2026-07-14, balance 250,000.00, rate 3.40% annual\nour accrual for July:\n daily_rate = 0.034 / 365 = 0.00009315068493150685\n days = 18\n accrued = 250000 * 0.00009315068493150685 * 18 = 419.1780821917808 → posted 419.18\ncore banking system's accrual for July: 419.17\ndifference: 0.01\n\nthe mainframe computes a daily amount, rounds each day to two decimals, and sums; we compute over the period and round once", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "ok so our SMTP queue grows without bound for one destination and the workers all end up stuck on it:\n\nqueue stats:\n total deferred: 412,882\n by destination: provider.example 411,004, everything else 1,878\n oldest deferred: 3 days\n workers busy: 32/32, all on provider.example\n\nsmtp-out log:\n 421 4.7.0 Too many concurrent connections from this IP, try again later\n (repeated, 41,882 times in the last hour)\n\nwe retry deferred messages every 60 seconds regardless of the destination's history, and we open a connection per message", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "la conciliación con el core bancario falla para las transferencias hechas el último día del mes:\n\ntransferencia 88412\n nuestra fecha valor: 2026-07-31T23:58:14Z\n fecha valor del core: 2026-08-01\n importe: 12.400,00 EUR\n estado en el core: liquidada\n estado en nuestro sistema: pendiente de conciliar\n\nel core opera en hora local (Madrid, UTC+2) y cierra el día contable a las 23:00; nosotros guardamos todo en UTC y conciliamos por fecha, no por instante", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "es"}
{"prompt": "our on-call runbook for mail delivery is one paragraph. what the team actually does:\n\n- \"mail is slow\" almost always means one destination is deferring and workers are stuck on it\n- `mailctl queue top` shows deferred counts by destination; anything over 10,000 for one destination is the cause\n- `mailctl throttle add provider.example --concurrency 4` limits us without pausing delivery\n- pausing a destination entirely is a last resort; the queue keeps growing and we have no disk alarm on it\n- if reputation has dropped, check the postmaster tools before touching anything, because sending harder makes it worse\n- never rotate DKIM keys during an incident, which we have now done twice\n\nwrite the runbook page in the order someone paged at 3am would need it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "the AR team's list, with the customer demo in six weeks:\n\n- colocation drift correction, which is the thing the demo needs\n- pinch detection ignoring stale poses, which makes the interaction feel broken\n- draw call reduction so we hold frame rate with a realistic scene\n- AnchorManager split, without which the first item is risky to attempt\n- session resume after the headset is removed, which enterprise customers keep asking for\n- hand menu on both hands, a small thing that testers mention every session\n\ntwo engineers, six weeks, and the demo is the only immovable thing", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "mail runbook should be a page rather than folklore, and rotating DKIM keys during an incident should be prevented rather than discouraged. write the runbook, then add the guard to the rotation command", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "statement view fails an accessibility audit on seven counts including an untagged PDF. fix what we can in the app, and write the remediation plan for the PDF pipeline, which is a bigger piece of work", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "our mail sending config across environments, and staging never reproduces deliverability issues:\n\n# staging\npools: { transactional: [10.0.0.1], marketing: [10.0.0.1], bulk: [10.0.0.1] }\nper_destination_concurrency: unlimited\nretry_interval: 60s\nmax_deferrals: 100\ndkim_selector: lumen2026\nfrom_domain: staging.lumen.io\n\n# prod\npools: { transactional: [4 IPs], marketing: [4 IPs], bulk: [4 IPs] } # all the same four IPs\nper_destination_concurrency: unlimited\nretry_interval: 60s\nmax_deferrals: 100\ndkim_selector: lumen2026\nfrom_domain: lumen.io", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "the compliance requirement for statement delivery, which now has a date:\n\n\"Statements must be delivered to the customer's registered address of record within two business days of the statement date. Electronic delivery is permitted where the customer has consented and where delivery can be evidenced. A bounced or undeliverable statement must trigger fallback to postal delivery within one business day. Evidence of delivery, including bounce handling, must be retained for seven years and be producible per customer on request.\"\n\nwe send electronically, retain bounce records for 90 days, have no postal fallback, and cannot currently produce a per-customer delivery history. i want the plan in order of regulatory risk", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "mail templates are rendered by two engines depending on which team created them", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "a walkthrough of how a card authorisation becomes two ledger entries would help", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "one queue abstraction, not three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "what guarantees does the batch make about ordering of postings within one account", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "statement view should let someone jump to a month without loading everything in between", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "honestly the AR anchors drift apart between two headsets in the same room:\n\nheadset A: anchor \"table\" at (1.204, 0.882, -2.114) confidence 0.91\nheadset B: anchor \"table\" at (1.188, 0.884, -2.098) confidence 0.88\nshared space: session s_4471, colocation via cloud anchors\ndrift over 10 minutes: A→B distance grew from 0.4cm to 4.1cm\nrelocalisation events: A 3, B 11\n\nwe resolve the cloud anchor once at session start and never re-resolve, and each headset applies its own tracking updates on top", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "i'm meant to approve this before it touches the ledger, and the transaction handling worries me:\n\n@Transactional(propagation = Propagation.REQUIRES_NEW)\npublic void applyBatch(List<Posting> postings) {\n int i = 0;\n for (Posting p : postings) {\n jdbc.update(INSERT_POSTING, p.account(), p.amountCents(), p.currency(), p.ref());\n jdbc.update(UPDATE_BALANCE, p.amountCents(), p.account());\n if (++i % 1000 == 0) {\n entityManager.flush();\n entityManager.clear();\n }\n }\n}\n\nthe batch is 88,000 postings, UPDATE_BALANCE touches a row per account, and accounts appear many times in one batch in no particular order", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "right, the pinch detector, which is the whole interaction model of the product:\n\npublic void Update() {\n var left = handSubsystem.GetHand(Handedness.Left);\n if (!left.TryGetJoint(XRHandJointID.IndexTip, out var index)) return;\n if (!left.TryGetJoint(XRHandJointID.ThumbTip, out var thumb)) return;\n var d = Vector3.Distance(index.position, thumb.position);\n if (d < pinchThreshold && state == State.Open) { state = State.Pinching; OnPinchStart?.Invoke(); }\n else if (d > releaseThreshold && state == State.Pinching) { state = State.Open; OnPinchEnd?.Invoke(); }\n lastIndex = index; lastThumb = thumb;\n}\n\nthere's no check on joint tracking confidence or pose timestamp, and TryGetJoint returns the last known pose rather than failing when tracking is lost", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "quick one — our retry and backoff for outbound mail, which i think is why one destination starves the queue:\n\nfunc (w *Worker) run() {\n for msg := range w.queue {\n if err := w.deliver(msg); err != nil {\n if isTemporary(err) {\n msg.NextAttempt = time.Now().Add(60 * time.Second)\n w.queue.Requeue(msg)\n continue\n }\n w.bounce(msg, err)\n }\n }\n}\n\nthirty-two workers share one queue, requeue puts the message back at the head, and there is no per-destination concurrency limit or backoff state", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "bitte prüfen, bevor das in die Abstimmung mit dem Kernbanksystem geht:\n\npublic LocalDate valueDate(Instant postedAt, String bookingCentre) {\n ZoneId zone = ZoneId.of(\"UTC\");\n return postedAt.atZone(zone).toLocalDate();\n}\n\npublic boolean isDuplicate(Posting p) {\n return dao.exists(p.ref(), p.amountCents(), valueDate(p.postedAt(), p.centre()));\n}\n\ndas Kernbanksystem bucht in Ortszeit des Buchungszentrums und schließt den Buchungstag um 23:00 Uhr; unsere Duplikatsprüfung stützt sich auf ein Datum, das in UTC berechnet wird", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "de"}
{"prompt": "fyi the DKIM signing configuration after monday's key rotation:\n\n# signing config\nselector: lumen2026\ndomain: lumen.io\nkey: /etc/lumen/dkim/lumen2026.private\nheaders: from:to:subject:date:message-id\ncanonicalization: relaxed/simple\n\n# DNS\nlumen2026._domainkey.lumen.io. TXT \"v=DKIM1; k=rsa; p=MIIBIjANBgkq...\" (published monday 11:04)\nlumen._domainkey.lumen.io. TXT \"v=DKIM1; k=rsa; p=MIIBIjANBgkq...\" (old selector, still published)\n\n# DMARC\n_dmarc.lumen.io. TXT \"v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s\"\n\nsome of our senders still use the old selector, and adkim=s means strict alignment", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "heads up: the design doc for our ledger's idempotency, which i suspect is where the double posting came from:\n\n## Idempotency\nA posting is uniquely identified by (reference, amount, value date). A repeated posting with the same triple is ignored.\n\n## Rationale\nThe card network guarantees a unique reference per authorisation, so this is belt and braces.\n\n## Consequences\n- A genuine repeat charge on the same day for the same amount is silently dropped.\n- Value date is computed at ingestion, in UTC.\n\n## Not covered\nReversals. Partial captures. Networks that reuse references across days.\n\nwe now know the network can send the same reference twice within seconds, and one of our booking centres is UTC+2", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "small thing but the query our statement generator runs per account, and month-end takes eleven hours:\n\nSELECT e.id, e.posted_at, e.amount_cents, e.currency, e.description,\n (SELECT balance_cents FROM balances b\n WHERE b.account_id = e.account_id AND b.as_of <= e.posted_at\n ORDER BY b.as_of DESC LIMIT 1) AS running_balance,\n (SELECT name FROM merchants m WHERE m.id = e.merchant_id) AS merchant\nFROM ledger_entries e\nWHERE e.account_id = $1 AND e.posted_at BETWEEN $2 AND $3\nORDER BY e.posted_at;\n\n4.1 million accounts, ledger_entries has 8.2 billion rows partitioned by month, balances is a snapshot table written daily", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the duplicate transactions, which need to become something we can send customers:\n\n- the card network occasionally sends the same authorisation twice, seconds apart\n- our duplicate check uses reference plus amount plus value date, computed in UTC\n- for our Madrid booking centre, a transaction after 22:00 local has a UTC date of the next day\n- when the two copies straddle that boundary they get different value dates and both post\n- the reversal arrives later and nets it out, so the customer's balance ends correct\n- but the statement shows three lines and the customer sees a double charge for up to 30 minutes\n- support currently explains this by hand, differently each time\n\nwrite the explanation support can send, and separately tell me which parts are bugs rather than explanations", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from the settlement failure, and the regulator will want this:\n\n01:02 batch SETTLE-20260729 starts, 88,214 postings\n02:41 batch fails at record 41,882 with a database deadlock\n02:41 rollback fails, connection closed; 41,881 postings are committed\n03:10 on-call escalates to the payments lead\n04:20 decision: do not re-run the batch, apply the remainder from a filtered file\n06:55 remaining 46,333 postings applied manually with a one-off script\n08:00 reconciliation with the core banking system passes\n09:30 customer impact assessed: 1,204 accounts saw a stale balance between 02:41 and 06:55\n\nwrite the incident report for our operational risk committee, who will ask why a partial batch was possible at all", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "as notas da reunião sobre a arquitetura de envio, para transformar em documento de decisão:\n\n- hoje temos um único conjunto de IPs para transacional, marketing e notificações\n- a reputação do domínio caiu depois de misturarmos recuperações de palavra-passe com marketing\n- a proposta é separar por subdomínio e por conjunto de IPs, com aquecimento progressivo\n- o aquecimento leva entre quatro e seis semanas e durante esse período a entrega é pior\n- alternativa: manter tudo junto e reduzir o volume de marketing, o que a equipa de growth recusa\n- há ainda a hipótese de usar um fornecedor externo só para marketing\n\nescreve a nota de decisão com as opções, os custos e uma recomendação", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "pt"}
{"prompt": "not urgent, but the auditor's questions on the ledger, which we've never answered in writing:\n\n1. How is a posting made idempotent, and what happens when the same reference arrives twice?\n2. Can a batch be partially applied, and how is that detected and remediated?\n3. Which staff can adjust a posted entry, and how is that evidenced?\n4. How are value dates determined across booking centres in different timezones?\n5. What is the reconciliation process against the core banking system, and what happens when it fails?\n6. How long are ledger entries retained and how is immutability assured?\n\nanswer each from the code and the runbooks, write it as a controls document, and mark anything you can't substantiate", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "社内向けのハンドトラッキング実装ガイドがありません。現状の挙動は次の通りです:\n\n- `TryGetJoint` はトラッキングが失われても最後の姿勢を返す。失敗しないので、呼び出し側で timestamp を確認する必要がある\n- 関節ごとに confidence 値があるが、我々のコードはどこでも見ていない\n- ピンチの閾値は 0.02m、リリースは 0.03m。ヒステリシスはあるが、手が遠いときの誤差は考慮していない\n- 片手が視界外に出ると、その手のイベントは発火しないまま状態が保持される\n- 60fps を下回るとフレーム間の移動量が大きくなり、閾値をまたぐ検出が不安定になる\n\nコード例:\n\nif (!left.TryGetJoint(XRHandJointID.IndexTip, out var index)) return;\nvar d = Vector3.Distance(index.position, thumb.position);\nif (d < pinchThreshold && state == State.Open) { ... }\n\n社内の開発者向けに、ハンドトラッキングを使う際の注意点をまとめたドキュメントを書いてください", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "ja"}
{"prompt": "genuinely puzzled by this: the settlement batch's operator guide, which is three commands and a warning. reality:\n\n- the batch runs at 01:00 and takes 90 minutes on a normal night, up to four hours at month end\n- it commits every 1,000 records with no checkpoint, so a failure leaves a partial batch and no safe restart\n- the recovery procedure is a one-off script that filters the input file by what's already applied\n- that script is written from scratch each time it's needed, by whoever is on call\n- reconciliation with the core system runs at 07:00 and will fail loudly if the batch is incomplete\n- there is a hard cut-off at 08:00 after which the business day starts and manual fixes are not permitted\n\nwrite the operator guide, and be explicit that the recovery procedure is currently improvised", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "spotbugs and error-prone on the ledger service, gate goes on next sprint:\n\nH C SIC: Should com.lumenbank.settlement.BatchRunner$Worker be a _static_ inner class?\nM P UPM: Private method PostingDao.checkpoint(long) is never called\nH C IS2: Inconsistent synchronization of BatchRunner.progress; locked 60% of time\nM D FS: Format string should use %n rather than \\n in StatementFormatter.render()\nH B RV: Return value of Instant.plus(long, TemporalUnit) ignored in ValueDate.forCentre()\n\nerror-prone:\n [BigDecimalEquals] BigDecimal.equals compares scale; use compareTo — Accrual.java:141\n\nthe ignored return value and the BigDecimal equals both look like real money bugs", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "unity's analyzer and our own lint rules, before the store build:\n\nAssets/Scripts/Hands/PinchDetector.cs(22,9): warning UNT0008: Null propagation on a UnityEngine.Object\nAssets/Scripts/Anchors/AnchorManager.cs(88,13): warning UNT0001: Empty Unity message 'Start'\nAssets/Scripts/Anchors/AnchorManager.cs(141,5): warning UNT0017: SetPixels invocation is slow, consider SetPixels32\nAssets/Scripts/Render/Tinter.cs(41,7): warning LUM0002: Material instance created per object; use MaterialPropertyBlock\nAssets/Scripts/Session/Keeper.cs(66,3): warning CS4014: call not awaited\n\n5 warnings and the material one is our whole draw-call problem", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "for context, the DNS records for our sending domain, one of these is why some mail fails DMARC:\n\nlumen.io. TXT \"v=spf1 include:_spf.lumen.io include:sendgrid.net ~all\"\n_dmarc.lumen.io. TXT \"v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@lumen.io\"\nlumen2026._domainkey.lumen.io. TXT \"v=DKIM1; k=rsa; p=MIIBIjANBg...\"\nlumen._domainkey.lumen.io. TXT \"v=DKIM1; k=rsa; p=MIIBIjANBg...\"\nmail.lumen.io. A 203.0.113.41\n\nour transactional mail signs with lumen2026 and sends From: [email protected]", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "background: the batch job's kubernetes manifest, and it was OOMKilled twice this month:\n\nresources:\n requests: { memory: 4Gi, cpu: \"2\" }\n limits: { memory: 4Gi, cpu: \"4\" }\nenv:\n - name: JAVA_OPTS\n value: \"-Xmx3g -XX:+UseG1GC\"\n - name: BATCH_COMMIT_SIZE\n value: \"1000\"\n - name: BATCH_FETCH_SIZE\n value: \"100000\"\nactiveDeadlineSeconds: 21600\nbackoffLimit: 0\n\nfetch size of 100,000 rows into a list, then processed in commits of 1,000", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependabot on the ledger service, four open and one is a CVE:\n\nspring-boot 3.3.2 → 3.3.5 (patch; includes a fix for a transaction manager regression)\noracle jdbc 23.4 → 23.6 (minor; batch execution behaviour changed for large batches)\njackson-databind 2.17.1 → 2.18.2 (CVE-2026-10112, deserialisation of untyped collections)\nlogback 1.5.6 → 1.5.13 (minor; JNDI lookup removed entirely)\n\nour batch runner uses oracle batch execution heavily and the JDBC changelog mentions \"executeLargeBatch now fails fast on the first error rather than continuing\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "les seuils d'alerte de la file d'attente mail, on nous réveille pour rien :\n\n- alert: MailQueueDepth\n expr: mail_queue_deferred_total > 1000\n for: 5m\n labels: { severity: page }\n\n- alert: MailWorkerBusy\n expr: mail_workers_busy / mail_workers_total > 0.9\n for: 1m\n labels: { severity: page }\n\n- alert: BounceRate\n expr: rate(mail_bounced_total[1h]) / rate(mail_sent_total[1h]) > 0.05\n for: 10m\n labels: { severity: ticket }\n\nen réalité : la file dépasse 1000 chaque nuit pendant l'envoi des relevés ; les workers sont à 100% dès qu'un destinataire ralentit ; et l'incident réel (réputation effondrée, DMARC rejeté) n'a déclenché que le ticket, découvert trois jours plus tard", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "fr"}
{"prompt": "this manager has accumulated everything anchor-related. same behaviour, separable pieces:\n\npublic class AnchorManager : MonoBehaviour {\n // resolves cloud anchors at session start\n // tracks local anchors and their confidence\n // owns the shared-space transform applied to all content\n // handles relocalisation after tracking loss\n // persists anchors to disk for session resume\n // drives the debug visualisation\n // subscribes to six XR subsystem events in Start and unsubscribes in none of them\n}\n\n900 lines, allocates in Update, and it's the class we most need to change for the drift fix", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "nuestro código de importe monetario está escrito de tres maneras en el mismo servicio:\n\n// Posting.java\nprivate final long amountCents;\n\n// Accrual.java\nprivate final BigDecimal amount; // escala variable, comparada con equals() en dos sitios\n\n// legacy/CoreAdapter.java\nprivate final double amount; // convertido a cents al escribir, con Math.round\n\nlos tres se convierten entre sí en los límites, la comparación con equals() de BigDecimal ya causó un descuadre en junio, y el double aparece en el adaptador que habla con el core bancario", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "es"}
{"prompt": "half-year planning input, needs sequencing:\n\n- the settlement batch has no checkpoint and a partial failure is now on the operational risk register\n- our value-date handling differs from the core banking system, which is behind three separate defects\n- AR colocation drift makes multi-user training sessions unusable past ten minutes\n- email reputation has to recover before the next statement run or a million statements go to spam\n- the ledger team loses two engineers to another division in september\n- there's a regulatory audit of the ledger in january\n- the AR product has a customer demo in six weeks that has been promised multi-user", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, thinking needed before anyone starts:\n\nLED-880 — Restartable settlement\nThe nightly batch commits every thousand records with no checkpoint, so a failure leaves a partial batch and recovery is an improvised script. The proposal is a checkpoint table and an idempotent apply, so the batch can be resumed from the last committed position. Concerns: postings are not currently idempotent at the record level, only at the (reference, amount, value date) level; the input file is not stable across reruns because it is regenerated from the source system; the batch's runtime is already close to the 08:00 cutover at month end; and the operational risk register wants a documented recovery time.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the mail operations console, which we stare at during deliverability incidents:\n\nDeliverability view\n- Per-destination table: deferred count, bounce rate, average latency, current concurrency, throttle state. Sorted by deferred descending.\n- A destination row expands to show the last 20 SMTP responses verbatim, which is what actually tells you what's wrong.\n- Reputation panel per pool: spam rate, domain reputation and IP reputation, with the provider's own thresholds marked.\n- Throttle controls inline per destination, with the current value and who set it last.\n- Queue age histogram, because \"how old is the oldest message\" is the question we always end up asking.\n- Everything read-only for on-call except throttles; pausing a destination requires a second person to confirm.\n- Must work on a phone, because this is what people open from bed.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings on the banking app's statement view, from a regulator-mandated audit:\n\n1. The running balance column is announced as a bare number with no context, so screen reader users hear a stream of digits.\n2. Debit and credit are distinguished by colour and a minus sign rendered as an image.\n3. The date filter is a custom control with no keyboard support and no announced state.\n4. The statement PDF has no tags at all, so it is unreadable by assistive technology.\n5. Focus order jumps between the filter bar and the entry list on every filter change.\n6. Amounts use a font where 3 and 8 are hard to distinguish at the default size, and the app overrides system text size.\n7. Error messages on failed transfers are announced only visually.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the banking app's transaction list actually uses:\n\ntokens:\n color.surface #FFFFFF / #0B0E11\n color.text.default #0B0E11 / #E9EEF3\n color.text.muted #5A6572\n color.amount.debit #B42318\n color.amount.credit #067647\n space 4/8/12/16/24, radius 8/12, focus 2px accent offset 2\n type: amount 17/22 tabular, body 15/20, caption 13/18\n\nthe transaction list: five hardcoded colours, amounts rendered in a proportional font so columns don't line up, a focus style removed on the row press target, and paddings of 6/11/15\n\nbring it onto the tokens, use the tabular figures for amounts, and restore the focus style", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "jackson CVE bump on the ledger", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "unpublish the old DKIM selector", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "hand menu on the left hand too", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "el importe sale sin separador de miles", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.15, "slice": "core", "lang": "es"}
{"prompt": "marketing off the transactional IPs", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "BigDecimal equals in Accrual.java", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "BounceRate should page, not ticket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "Xmx passt nicht zum Memory-Limit", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
{"prompt": "ignored return value in ValueDate", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "tracking quality needs a shape, not a colour", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "amounts need tabular figures", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "expand a destination to see SMTP replies", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "our mail workers, queue and throttling are one package with the policy inline:\n\nfunc (w *Worker) deliver(msg *Message) error {\n conn, err := smtp.Dial(msg.Destination.MX[0] + \":25\") // no pooling, no per-destination limit\n ...\n if isTemporary(err) {\n msg.NextAttempt = time.Now().Add(60 * time.Second) // policy inline\n return w.queue.Requeue(msg)\n }\n ...\n}\n\ni want the delivery policy — concurrency per destination, backoff schedule, deferral limits — expressed somewhere it can be tested and changed without touching the SMTP code, with today's behaviour as the default", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "the core banking system's interface spec, which we implement against:\n\nMQ-based, fixed-width records, one message per posting\n fields: account (10), amount (13, implied 2 decimals, sign in the last byte), currency (3), value date (8, YYYYMMDD, booking centre local), reference (16), centre (4)\n the core acknowledges each message with a status record; an unacknowledged message must be resent with the same reference\n a resent message that the core already applied returns status 'DUP' and must be treated as success\n the daily cutover is 23:00 booking centre local; messages after cutover carry the next business date\n business dates skip weekends and the centre's holiday calendar, which we receive as a yearly file\n the core rejects a batch if any record's value date is more than one business day in the past", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "mail console should show the oldest deferred message per destination, which is what we always ask", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "手のメニューが片手でしか出せません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "ja"}
{"prompt": "minus signs are rendered as images", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "boundary", "lang": "en"}
{"prompt": "date filter has no keyboard support", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "app overrides system text size", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "console is unusable on a phone", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "property blocks instead of material instances", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "un seul rendu de relevé, trois formats", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "fr"}
{"prompt": "`posted_at` naming, be consistent", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "split relocalisation out of AnchorManager", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "inline `isTemporary`, one caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "changelog for the AR 3.1 release", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota interna sobre a separação de IPs", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "pt"}
{"prompt": "document the 23:00 cutover rule", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the checkpoint proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the drift correction", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "can a batch commit half a transfer?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "¿por qué el DMARC rechaza algunos correos?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "es"}
{"prompt": "walk me through the reconciliation job", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "pinch stops working after a few minutes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "one destination starves the mail queue", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "warum bucht der Batch nur die Hälfte?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a customer's delivery history", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "keep going on it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "fewer alerts", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "whatever the auditors will ask about", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo del correo, sigue", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "es"}
{"prompt": "anchors, again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "tidy the ledger code", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "same as before", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "controls doc", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "something safe for a friday", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "another set of eyes", "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": "onto the next one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "value dates disagree with the core banking system in three different ways depending on which of our four implementations you hit, and each disagreement has produced a defect. rather than fix them one at a time i want a position on where value date should be computed, who owns the business calendar, and how we'd prove agreement with the core continuously rather than at month end", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "multi-user AR sessions are unusable past about ten minutes because shared anchors drift, and the demo in six weeks has been promised multi-user. i want the approach decided properly — periodic re-resolution, relative correction between clients, or a different colocation mechanism entirely — with an honest view of what's achievable in six weeks versus what's the real fix", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "transactional email API is used by six teams from a wiki page written before the pools existed, and choosing the wrong pool degrades deliverability for everyone. write the reference documentation properly, with the pool guidance up front, the silent behaviours stated, and the rate limits published rather than discovered the last person who touched this left, so there's nobody to ask.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "settlement batch's operator guide is three commands and a warning, while the real recovery procedure is improvised from scratch each time by whoever is on call at four in the morning. write the guide honestly, including that the recovery script does not exist, because pretending otherwise is how we got here i'd like enough detail that i can hand it to someone else to finish.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "support explains our duplicate-transaction behaviour differently every time because nobody has written down what actually happens with the reference, the value date and the reversal. write the explanation they can send to a customer, in plain language, without implying the customer was charged twice when the balance was never wrong if the answer is that it's fine as it is, that's a useful answer too.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "idempotency design doc says a card reference is unique per authorisation and treats that as belt and braces, which we now know is wrong in at least two ways. read it against the code and the incident and tell me which of its other assumptions are load-bearing, because i suspect the value-date one is worse than the reference one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "colocation approach resolves a cloud anchor once and never revisits it, which the drift numbers suggest is the whole problem, but i'd like that confirmed rather than assumed before we commit six weeks to a fix. read the anchor lifecycle and the relocalisation path and tell me where the error actually accumulates a rough ordering matters more to me than a complete answer right now.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "money is represented as long cents, BigDecimal and double in the same service, converted at every boundary, and one BigDecimal equals comparison already caused a reconciliation break. settle on one representation, convert at the edges only, and prove that every posting from last month produces an identical amount afterwards this is the third time it's bitten us and i'd like it to be the last.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "instructor panel is what makes multi-user sessions manageable and right now it's a debug canvas with a participant count. build it to the spec — tracking quality as shape and colour, step control with confirmation, recentre-everyone with per-headset results — and make sure it's legible while the instructor walks", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "before we make the batch restartable i want the checkpoint semantics agreed — what a checkpoint covers, what happens to a partially applied commit, how the input file is made stable — and then the checkpoint table and resume path implemented against it", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "IP and domain separation for mail needs a plan with a warm-up schedule, and it needs the transactional subdomain standing up now so the warm-up can start. give me the plan, then do the subdomain, DKIM and SPF setup for it i'd rather have the reasoning written down than a quick answer.", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "anchor drift needs a proper design and the demo needs something in six weeks. work out the correction approach with me, then implement periodic re-resolution as the shippable subset, keeping the full design written down for afterwards", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "unsere Wertstellungslogik existiert viermal und weicht dreimal vom Kernbanksystem ab. Ich hätte gern zuerst eine Festlegung, wo das Datum berechnet wird und wem der Buchungskalender gehört, und danach die Zusammenführung an einer Stelle", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "de"}
{"prompt": "our statement rendering is duplicated for PDF, HTML email and the CSV export:\n\n// StatementPdf.java — iterates entries, formats amounts with a NumberFormat in the user's locale\n// StatementHtml.java — iterates entries, formats amounts with String.format(\"%,.2f\")\n// StatementCsv.java — iterates entries, writes raw cents\n\nall three compute the running balance independently; the PDF one is the regulated artefact; and the HTML one has a rounding difference on negative amounts that a customer noticed last month", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "the schema we agreed for delivery evidence, now it needs building:\n\nCREATE TABLE delivery_events (\n id bigserial PRIMARY KEY,\n message_id uuid NOT NULL,\n customer_id uuid NOT NULL,\n kind text NOT NULL CHECK (kind IN ('queued','sent','delivered','deferred','bounced','complained','suppressed')),\n destination text NOT NULL,\n smtp_response text,\n occurred_at timestamptz NOT NULL,\n provider_id text\n);\nCREATE INDEX ON delivery_events (customer_id, occurred_at DESC);\n\nseven year retention, immutable once written, must be producible per customer within a working day, and must drive an automatic postal fallback when a statement bounces — which means the bounce has to be classified as permanent or temporary reliably", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "delivery evidence has a seven-year retention requirement and no design. decide with me what we record, how it stays immutable and how the postal fallback is triggered, then build the event write path", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "email API reference has to exist before another team picks the wrong pool, and while writing it please confirm whether send_at really clamps silently at seven days, because two teams believe it errors", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "hand-tracking guide needs writing and i suspect it will surface behaviours we should fix rather than document — the stale pose one especially. write the guide, and give me that list separately", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la guía del operador para el batch de liquidación y comprueba en el código si el commit cada mil registros puede partir una transferencia en dos, porque de eso depende todo lo demás", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "es"}
{"prompt": "tinting via material instances is the whole draw-call problem and the fix is property blocks. make the change, and document the rendering conventions so the next feature doesn't reintroduce it", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "three queue abstractions should become one, and i'd like to know first whether any of them is actually load-bearing for ordering guarantees. check that, then consolidate", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "AnchorManager needs splitting before the drift work lands. do the split, then write the short note on which class owns the shared transform, because that's the question every bug report ends up being about", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "accruals differ from the core system by a cent for accounts opened mid-month, which looks like a rounding-frequency difference. confirm that from the code, then align our calculation and tell me how many accounts are affected historically", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "queue starves whenever one destination defers, and thirty-two workers all end up on it. diagnose it properly, then implement per-destination concurrency so a slow provider can't take the whole sender down", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "headset drops to 45fps in one area and the profiler blames draw calls, but i want the cause confirmed rather than inferred. work through it, then do whichever fix the evidence supports", "purpose": "debugging", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "transaction list ignores the tokens and renders amounts in a proportional font. bring it onto the tokens with tabular figures, and tell me whether the amount column width changes enough to affect the layout on small phones", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "core banking adapter needs to handle the DUP status as success rather than an error, and we should agree what a resend means for our own idempotency first. decide that, then implement", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "rename `Posting.ref`, it's the card network's reference in one place and ours in another", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "could you explain how a reversal is matched to the original posting when the reference repeats", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "is our suppression list checked at enqueue as well as at send, or only at send", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "why does the statement generator take eleven hours at month end when it's one query per account", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "missing template variables should fail loudly rather than rendering as an empty string, which is how one team shipped a statement email with a blank amount. change the default, give the forty-odd templates that rely on the current behaviour an explicit opt-out, and tell me which ones actually need it keep it concrete — file names and line numbers are more use than principles here.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment la date de valeur est calculée pour un centre en UTC+2 ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/settlement.md describes a restartable batch, which is aspirational rather than true", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "a short note on why we're separating the sending domains, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "API changelog needs an entry for the pool parameter becoming required", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "javadoc on applyBatch promises atomicity that the commit-every-thousand loop doesn't provide", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "write the customer note about statements moving to a new sending domain", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "health check reports the batch service healthy while the last run failed halfway", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "staging sends from a single IP for all three pools, which is why pool bugs never appear there", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "how should we handle a booking centre in a timezone we don't currently support", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to test money code where the failure mode is a regulatory finding", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether AR session state should live on the headset or the server", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "two teams want to send mail through us with their own domains, what should the tenancy model be", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "we need a plan for supporting a second core banking system for the acquired bank", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to a scheduled send when the template is edited before it goes out", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns a posting's full lineage — source message, batch, reversals, adjustments", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "shared anchors should re-resolve on a timer with a drift correction applied between clients", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "deliverability view needs a per-pool reputation panel with the provider's thresholds marked", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "participant list should show who has fallen behind a step, not just who is connected", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "whatever's safe before month end", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "next bit of the mail work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "batch runner and the online posting path each update balances with different locking, which is why a batch running during business hours can deadlock against normal traffic. bring them onto one path with one locking strategy, and tell me which of the two behaviours we're actually keeping, because they differ on ordering within an account", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like an honest read on whether a support user can adjust a posted entry without leaving an audit trail, given the admin tooling and the direct database access two people still have, and the smallest change that closes it before january assume whoever picks it up next has no context beyond what you write.", "purpose": "review", "secondary": "planning", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "per-destination backoff state has to survive a restart, and the shape of that state depends on whether we treat a destination as an MX host or a domain. decide that with me — the two behave differently for providers with shared infrastructure — then implement it the sooner we know roughly how big this is, the better for planning.", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "internal page on the reconciliation process stops at \"the job compares both sides\" and everything that matters — what a break is, who investigates, what the cutover time means — is folklore. write the page properly, following one break from detection to resolution, and name the systems and people involved at each step i've already spent an afternoon on it and got nowhere useful.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "AR session times out sixty seconds after a headset is removed, while enterprise customers run training where instructors take headsets off routinely for five minutes at a time. raise the timeout, make it configurable per deployment, and make sure a session that does expire tells participants why rather than simply disappearing this has come up in three separate reviews now and never gets done.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "mail templates are rendered by two engines depending on which team created them, which means a variable that works in one silently produces nothing in the other, and neither team knows which engine their template uses. consolidate onto the newer engine, migrate the older templates, and diff the rendered output for a sample of each so nothing changes under a customer's nose", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "ledger service schedules work three ways — quartz, a database poller and a cron container — and which one a job uses depends entirely on when it was written. settle on one mechanism, migrate the jobs, and make sure the ones with strict timing relative to the settlement batch keep their ordering guarantees it doesn't have to be elegant, it has to be defensible in a review.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "`Posting.ref` means the card network's reference in the ingestion path and our own generated reference everywhere else, which is exactly the confusion behind the duplicate posting incident. give the two concepts different names throughout, keep the database columns as they are for now, and flag any place where the ambiguity is currently load-bearing", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "nobody can tell me what the reconciliation job does when it finds a break at month end, specifically whether it stops, continues, or quietly writes an adjustment. read the job and its runbook together and tell me what really happens, and how many breaks went through that path last quarter flag anything you'd want to change before doing it rather than after.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "statement generator issues one query per account with two correlated subqueries inside it, and month end takes eleven hours against a nine hour window. before anyone rewrites it i want to know where the time actually goes and whether the balances snapshot table is being used at all there's no rush on this week specifically, but it keeps costing us time.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "suppression list is checked at send time rather than at enqueue, so a statement scheduled a week ahead can go to an address that unsubscribed yesterday, which is a compliance problem rather than an inconvenience. check at both points, keep the send-time check as the authority, and record which check suppressed a message the last person who touched this left, so there's nobody to ask.", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt":"One contained cleanup in projects/longbow/cmd/exporter/main.py: remove the obsolete LongbowPineMetricsFlow import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"LongbowMoonlitSDKCoordinator: diagnose, then correct","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Apparently: Check LongbowEmberRelayService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Before we approve LongbowMarbleTokenStore, assess whether an accessibility label that reads the internal enum is an actual correctness risk or merely confusing structure. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: LongbowHarborIndexStore has one known configuration mistake in projects/longbow/internal/auth/refresh.go, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Playwright deployment\n- keep the work scoped to LongbowHarborIndexStore and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Before touching projects/longbow/infra/modules/edge/main.tf, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Lately: projects/longbow/web/components/FilterDrawer.vue 里的 LongbowAmberFilterStore 最近在 Playwright 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 Playwright\n- 保持兼容性和取消语义\n- 改动只限于 LongbowAmberFilterStore","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"zh"}
{"prompt":"Read projects/longbow/crates/index/src/segment.rs and tell me whether LongbowJuniperCLIFlow can acknowledge work before its durable write completes; this is a read-only safety pass. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-52139: retire the legacy replay path for LongbowSummitProxyFlow\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 LongbowSummitProxyFlow 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":"LongbowMarbleTokenCoordinator: handle the lingering thing","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Oddly: // projects/longbow/Sources/CLI/Commands/Doctor.swift\nfinal class LongbowBasilRunnerFlowCoordinator {\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 LongbowBasilRunnerFlow 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":"LongbowMapleQueueCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"On compact widths, LongbowMarbleTokenService's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for LongbowCinderAuthStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Fresh release brief for LongbowCraneWorkspaceCoordinator:\n- primary outcome: change LongbowCraneWorkspaceCoordinator'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/longbow/lib/codec/frame.cc\n- platform constraint: Core Data\n- known complication: a deadlock that appears only during shutdown\n\nBoth results are required, but they should remain independently reviewable. Leave generated files and vendored code alone; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Fresh release brief for LongbowNovaPickerCoordinator:\n- primary outcome: assess ownership and failure handling in projects/longbow/cmd/exporter/main.py\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/longbow/cmd/exporter/main.py\n- platform constraint: Redis Streams\n- known complication: a flaky snapshot caused by locale-dependent sorting\n\nBoth results are required, but they should remain independently reviewable. Leave generated files and vendored code alone; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"LongbowAtlasSearchService'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":"The minimum supported React 19 version in projects/longbow/db/migrations/20260730_events.sql is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Please turn LongbowWrenExportStore's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"projects/longbow/db/migrations/20260730_events.sql now contains LongbowCedarPolicyStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"En projects/longbow/apps/console/routes/usage.svelte, LongbowCloudReconcilerStore tiene un problema intermitente en el flujo de React 19. Sigue queue, scheduler y cancelación, compara hipótesis y encuentra la causa antes de proponer cambios.\n\nRestricciones:\n- seguir con React 19\n- conservar compatibilidad y cancelación\n- limitar el cambio a LongbowCloudReconcilerStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"es"}
{"prompt":"Currently: # projects/longbow/infra/modules/edge/main.tf\n[worker.longbowbirchmigratorflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longbowbirchmigratorflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longbowbirchmigratorflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowBirchMigratorFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52128\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 LongbowBirchMigratorFlow'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":"Match LongbowMoonlitSDKStore's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'LongbowLedgerGateCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowLedgerGateCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/web/components/FilterDrawer.vue:144: error: -[LongbowLedgerGateCoordinatorTests 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 '-[LongbowLedgerGateCoordinatorTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Find the source of this LongbowLedgerGateCoordinator symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"LongbowWrenExportCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Summarize the LongbowRavenSessionService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Today: This should remain a deliberately small patch: LongbowRainfallDBService has one known configuration mistake in projects/longbow/workers/thumbnail/consumer.ex, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Core Data deployment\n- keep the work scoped to LongbowRainfallDBService and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Architect a gradual ownership transfer for LongbowBeaconStoreStore across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Architect a gradual ownership transfer for LongbowWrenExportService across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_52133'\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_52133'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nDetermine why LongbowEchoRegistryFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Split LongbowOpalRouterService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Give LongbowCinderAuthService a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Context: // projects/longbow/Sources/CLI/Commands/Doctor.swift\nfinal class LongbowFrostPanelCoordinatorCoordinator {\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 LongbowFrostPanelCoordinator; 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":"Security flagged LongbowPineMetricsService for a read-only pass because its Redis Streams boundary mixes tenant data, retries, and cancellation in subtle ways. 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- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Redis Streams operational envelope\n\nThis repository spans billing, Elixir, Android; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Describe LongbowBirchMigratorService's error envelope","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Give LongbowLedgerGateStore's detail pane a sticky action bar, fluid type at narrow widths, and a keyboard-safe scroll region that still works at 200% zoom.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up LongbowOpalRouterCoordinator. First, finish LongbowOpalRouterCoordinator's responsive empty and retry states. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/longbow/crates/index/src/segment.rs, which follows Terraform conventions and currently suffers from an empty state that flashes before cached data arrives. Leave generated files and vendored code alone.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Trace LongbowBirchMigratorStore's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Is there a cleaner way to separate LongbowBeaconStoreService's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Decouple LongbowPrismCacheService's storage policy","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"PM needs a concise migration note for LongbowFrostPanelStore, 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":"LongbowFernSnapshotFlow 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":"Our support and SDK teams keep answering the same questions about LongbowAsterWebhookService, but the current prose in projects/longbow/Sources/CLI/Commands/Doctor.swift only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Redis Streams deployment\n- keep the work scoped to LongbowAsterWebhookService and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"The behavior of LongbowCopperBridgeStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/longbow/packages/api/openapi.yaml. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Terraform operational envelope\n\nThis repository spans billing, Elixir, Android; use its existing conventions rather than importing a new abstraction.\n\nProduce durable prose rather than a code assessment or implementation change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"# projects/longbow/crates/index/src/segment.rs\n[worker.longboworbitsyncflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longboworbitsyncflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longboworbitsyncflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowOrbitSyncFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52144\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/longbow/crates/index/src/segment.rs. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"For LongbowWillowCodecCoordinator, find the unknown cause of lost focus when the drawer animation finishes; once that is complete, give the existing implementation a read-only safety pass. Work from projects/longbow/lib/codec/frame.cc, stay with Core Data, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Background: The LongbowRainfallDBStore surface in projects/longbow/ui/settings/PrivacyPane.tsx 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":"Ticket OPS-52155: retire the legacy replay path for LongbowPineMetricsCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible LongbowPineMetricsCoordinator 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":"I inherited LongbowOpalRouterStore and need a careful read of projects/longbow/crates/index/src/segment.rs before I can sign off on the next release. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Terraform deployment\n- keep the work scoped to LongbowOpalRouterStore and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.\n\nReturn an assessment of the existing artifact; only quote enough to make the walkthrough understandable.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"LongbowIrisBatchCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"What sequence would let LongbowQuartzPlayerService adopt Terraform with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/longbow/packages/api/openapi.yaml b/projects/longbow/packages/api/openapi.yaml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/longbow/packages/api/openapi.yaml\n+++ b/projects/longbow/packages/api/openapi.yaml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nSplit LongbowCopperBridgeCoordinator by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"LongbowRavenSessionCoordinator: restructure, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Question: Ticket OPS-52111: retire the legacy replay path for LongbowCloudReconcilerFlow\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 LongbowCloudReconcilerFlow 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":"Test Suite 'LongbowRavenSessionFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowRavenSessionFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/services/ledger/replay.go:144: error: -[LongbowRavenSessionFlowTests 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 '-[LongbowRavenSessionFlowTests 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\nBring LongbowRavenSessionFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"LongbowSummitProxyCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"LongbowEmberRelayStore leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-52124\n\n08:02 deploy LongbowFlintTimelineFlow 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 LongbowFlintTimelineFlow 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":"Cadre la migration de LongbowDeltaCanvasService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"fr"}
{"prompt":"# CI job 52112: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Core Data\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] LongbowCraneWorkspaceFlowIntegration.replays_after_timeout ... ok\n[test] LongbowCraneWorkspaceFlowIntegration.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\nDeliver the LongbowCraneWorkspaceFlow 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.8,"slice":"pasted-context","lang":"en"}
{"prompt":"We expect LongbowJuniperCLIService to outgrow its current Terraform arrangement next quarter, but changing everything at once would be risky. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Terraform deployment\n- keep the work scoped to LongbowJuniperCLIService and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"LongbowCoralUploadCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Observation: Architect a gradual ownership transfer for LongbowRainfallDBFlow across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/longbow/pkg/cache/lease.rs b/projects/longbow/pkg/cache/lease.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/longbow/pkg/cache/lease.rs\n+++ b/projects/longbow/pkg/cache/lease.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\nDeliver the LongbowJuniperCLICoordinator 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.8,"slice":"pasted-context","lang":"en"}
{"prompt":"What does LongbowWillowCodecService own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-52145: retire the legacy replay path for LongbowBeaconStoreFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Using this as the starting evidence, propose a staged LongbowBeaconStoreFlow 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":"Is LongbowMoonlitSDKService safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Constraint: # projects/longbow/ml/pipeline/features.py\n[worker.longbownovapickerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longbownovapickerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longbownovapickerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowNovaPickerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52115\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/longbow/ml/pipeline/features.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Request: # projects/longbow/engine/render/atlas.cpp\n[worker.longbowwillowcodecflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longbowwillowcodecflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longbowwillowcodecflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowWillowCodecFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52132\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/longbow/engine/render/atlas.cpp. 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":"Assess the LongbowFlintTimelineStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"How does LongbowQuartzPlayerStore propagate cancellation through the Terraform boundary, and are there code paths where ownership becomes ambiguous? I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Goal: diff --git a/projects/longbow/cmd/exporter/main.py b/projects/longbow/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/longbow/cmd/exporter/main.py\n+++ b/projects/longbow/cmd/exporter/main.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate LongbowMicaProfileFlow'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":"Before we approve LongbowMosaicGridService, 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.4,"slice":"core","lang":"en"}
{"prompt":"Symptom: What is the safest way to split projects/longbow/packages/api/openapi.yaml into independently owned modules while LongbowSummitProxyService's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"projects/longbow/ml/pipeline/features.py 里的 LongbowMapleQueueService 最近在 Redis Streams 流程中出现间歇性问题。 请拆分职责并去掉重复，同时保持 API、wire value、顺序和可观察行为不变。\n\n约束：\n- 继续使用 Redis Streams\n- 保持兼容性和取消语义\n- 改动只限于 LongbowMapleQueueService","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Draft LongbowMicaProfileService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-52158: finish the compact LongbowHarborIndexCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/longbow/internal/auth/refresh.go\nFramework: Playwright\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 LongbowHarborIndexCoordinator'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":"Headsup: // projects/longbow/db/migrations/20260730_events.sql\nfinal class LongbowCedarPolicyCoordinatorCoordinator {\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 LongbowCedarPolicyCoordinator; 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":"Test Suite 'LongbowDeltaCanvasFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowDeltaCanvasFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/packages/api/openapi.yaml:144: error: -[LongbowDeltaCanvasFlowTests 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 '-[LongbowDeltaCanvasFlowTests 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 LongbowDeltaCanvasFlow'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":"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_52131'\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_52131'::text)\n Filter: (created_at >= (now() - '24:00:00'::interval))\n Rows Removed by Filter: 8045512\nPlanning Time: 2.814 ms\nExecution Time: 8423.104 ms\n\nPostgreSQL 17.2, default_statistics_target=100. The same query was under 300 ms last week, no migration landed, and an ANALYZE temporarily returns it to normal.\n\nWire LongbowEmberRelayFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.9,"slice":"pasted-context","lang":"en"}
{"prompt":"LongbowEmberRelayCoordinator needs a paired pass: separate LongbowEmberRelayCoordinator's policy from transport without behavior changes, plus correct the known stale timeout beside it. Use projects/longbow/apps/console/routes/usage.svelte as the source of truth, preserve the React 19 contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"The API work is done; what remains for LongbowFrostPanelService is the visible interaction layer across loading, offline, empty, and success cases. Bring the drawer and detail pane to production polish with fluid sizing, honest skeletons, focus restoration, accessible announcements, and touch targets that survive large text.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowFrostPanelService\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android 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":"Translate the LongbowEchoRegistryStore setup notes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"FYI: Test Suite 'LongbowMapleQueueFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowMapleQueueFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/ml/pipeline/features.py:144: error: -[LongbowMapleQueueFlowTests 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 '-[LongbowMapleQueueFlowTests 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\nBring LongbowMapleQueueFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"LongbowQuartzPlayerCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"vague-eval","lang":"en"}
{"prompt":"Release engineering needs a LongbowDriftConsoleStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Move LongbowSummitProxyStore'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":"Meanwhile: Test Suite 'LongbowSpruceDaemonFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowSpruceDaemonFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/config/staging.toml:144: error: -[LongbowSpruceDaemonFlowTests 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 '-[LongbowSpruceDaemonFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Bring LongbowSpruceDaemonFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"UI ticket DES-52136: finish the compact LongbowKiteSchedulerFlow filter experience\n\nRoute: /catalog/search\nSource: projects/longbow/db/migrations/20260730_events.sql\nFramework: React 19\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible LongbowKiteSchedulerFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Could LongbowCedarPolicyFlow show the active React 19 sync phase as an accessible progress row, including reduced-motion behavior?","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Locally: The behavior of LongbowHarborIndexService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/longbow/infra/modules/edge/main.tf. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Playwright operational envelope\n\nThis repository spans billing, Elixir, Android; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Introduce a durable deduplication key for LongbowOrbitSyncStore events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Warum hängt LongbowDeltaCanvasStore?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"This should remain a deliberately small patch: LongbowTideWorkerService has one known configuration mistake in projects/longbow/web/components/FilterDrawer.vue, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Playwright deployment\n- keep the work scoped to LongbowTideWorkerService and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"LongbowMicaProfileCoordinator needs a paired pass: separate LongbowMicaProfileCoordinator's policy from transport without behavior changes, plus correct the known stale timeout beside it. Use projects/longbow/ml/pipeline/features.py as the source of truth, preserve the Redis Streams contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Production: Ticket OPS-52137: retire the legacy replay path for LongbowVelaDrawerFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. From this evidence, draft consumer-facing migration guidance for LongbowVelaDrawerFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"# projects/longbow/Sources/App/SessionStore.swift\n[worker.longbowgarnetmodalflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longbowgarnetmodalflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longbowgarnetmodalflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowGarnetModalFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52120\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/longbow/Sources/App/SessionStore.swift. 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":"LongbowSableParserCoordinator: polish, then assess","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"LongbowIrisBatchStore's staging timeout is already known to be wrong: change the single projects/longbow/engine/render/atlas.cpp value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"LongbowNimbusFormService's frame.cc needs better comments","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"LongbowKiteSchedulerService 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.6,"slice":"core","lang":"en"}
{"prompt":"Two asks around LongbowLumenChartCoordinator: (1) find the unknown cause of a feature flag whose default differs between environments; (2) correct the known stale timeout beside it. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"debugging","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"LongbowAcornWidgetCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Staging: // projects/longbow/internal/auth/refresh.go\nfinal class LongbowMarbleTokenFlowCoordinator {\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 LongbowMarbleTokenFlow 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":"Enforce LongbowEchoRegistryService's idempotency key","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"LongbowBirchMigratorCoordinator needs a paired pass: produce a consumer guide for LongbowBirchMigratorCoordinator, plus give the existing implementation a read-only safety pass. Use projects/longbow/internal/auth/refresh.go as the source of truth, preserve the Playwright contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Billing: Before touching projects/longbow/infra/modules/edge/main.tf, 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":"PM is preparing the LongbowCopperBridgeService rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowCopperBridgeService\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"In projects/longbow/app/src/main/SyncWorker.kt hat LongbowCloudReconcilerService ein sporadisches Problem im React 19-Ablauf. Lies den aktuellen Ablauf und bewerte Ownership, Abbruch und Reihenfolge; ich brauche nur die Analyse.\n\nRandbedingungen:\n- React 19 weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf LongbowCloudReconcilerService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um LongbowCloudReconcilerService mit React 19 kompatibel.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"de"}
{"prompt":"LongbowKiteSchedulerStore's staging timeout is already known to be wrong: change the single projects/longbow/src/sync/reconcile.ts value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"A previously stable test around LongbowDriftConsoleService 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":"CI: # projects/longbow/web/components/FilterDrawer.vue\n[worker.longbowtideworkerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longbowtideworkerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longbowtideworkerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowTideWorkerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52113\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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Align LongbowTideWorkerFlow'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.3,"slice":"pasted-context","lang":"en"}
{"prompt":"Release verification found a single stale LongbowCraneWorkspaceStore value; the cause, desired value, and affected assertion are already agreed. 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- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Core Data operational envelope\n\nThis repository spans billing, Elixir, Android; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'LongbowWrenExportFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowWrenExportFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/workers/thumbnail/consumer.ex:144: error: -[LongbowWrenExportFlowTests 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 '-[LongbowWrenExportFlowTests 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\nBring LongbowWrenExportFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-52116\n\n08:02 deploy LongbowOspreyJobFlow 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 LongbowOspreyJobFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-52126\n\n08:02 deploy LongbowCinderAuthFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the LongbowCinderAuthFlow 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":"Corrija o timeout de LongbowLumenChartService","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"pt"}
{"prompt":"Compare the old and new LongbowVelaDrawerService 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":"Bring LongbowPineMetricsStore'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":"Ticket OPS-52151: retire the legacy replay path for LongbowSlateEditorCoordinator\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 LongbowSlateEditorCoordinator 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":"Atlas: Test Suite 'LongbowMoonlitSDKFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowMoonlitSDKFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/apps/console/routes/usage.svelte:144: error: -[LongbowMoonlitSDKFlowTests 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 '-[LongbowMoonlitSDKFlowTests 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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Finish the visible LongbowMoonlitSDKFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"LongbowMosaicGridCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"LongbowPrismCacheCoordinator: ship, then assess","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Compare the old and new LongbowAtlasSearchStore adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits. I want your judgment and walkthrough, not new documentation.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-52110: retire the legacy replay path for LongbowAsterWebhookFlow\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 LongbowAsterWebhookFlow 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":"// projects/longbow/pkg/cache/lease.rs\nfinal class LongbowOpalRouterFlowCoordinator {\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 LongbowOpalRouterFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Persist LongbowLedgerGateFlow delivery attempts in projects/longbow/services/ledger/replay.go, claim them safely across workers, and make duplicate webhook receipts return the original accepted result.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two asks around LongbowFlintTimelineCoordinator: (1) finish LongbowFlintTimelineCoordinator's responsive empty and retry states; (2) give the existing implementation a read-only safety pass. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"PM needs a concise migration note for LongbowOrbitSyncService, 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":"Beacon: Release engineering needs a LongbowJuniperCLIStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Extract LongbowOspreyJobService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"LongbowAsterWebhookCoordinator is blocking the next release because cancellation being swallowed at the repository boundary. I need two concrete outcomes from a single pass: lay out a staged migration for LongbowAsterWebhookCoordinator, and consolidate the duplicated normalization paths without changing behavior. Use the existing Redis Streams conventions in projects/longbow/Sources/App/SessionStore.swift; leave generated files and vendored code alone. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Ownership of LongbowFernSnapshotService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Give me a staged design with ownership boundaries, compatibility seams, migration order, telemetry, failure drills, rollback criteria, and explicit decisions we can defer; stop before implementation.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Core Data operational envelope\n\nThis repository spans billing, Elixir, Android; use its existing conventions rather than importing a new abstraction.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"LongbowAmberFilterCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"The public surface of LongbowAsterWebhookStore is frozen, but its internal ownership in projects/longbow/Sources/App/SessionStore.swift is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowAsterWebhookStore\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Cinder: Ticket OPS-52117: retire the legacy replay path for LongbowPrismCacheFlow\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 LongbowPrismCacheFlow 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":"For LongbowCinderAuthCoordinator, assess ownership and failure handling in projects/longbow/db/migrations/20260730_events.sql; once that is complete, capture the contract and rollback note for consumers. Work from projects/longbow/db/migrations/20260730_events.sql, stay with React 19, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Spell LongbowSableParserStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Introduce a durable deduplication key for LongbowCoralUploadService events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Assess the LongbowWillowCodecStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"# CI job 52127: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Core Data\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] LongbowLumenChartFlowIntegration.replays_after_timeout ... ok\n[test] LongbowLumenChartFlowIntegration.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\nDetermine why LongbowLumenChartFlow produces this result. Trace ordering, cancellation, shared state, and scheduler behavior; identify the root cause before suggesting a patch.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Check LongbowNovaPickerService's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"LongbowTideWorkerCoordinator is blocking the next release because out-of-order events after consumer rebalancing. I need two concrete outcomes from a single pass: change LongbowTideWorkerCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing Playwright conventions in projects/longbow/services/ledger/replay.go; leave generated files and vendored code alone. Keep the outcomes distinct so reviewers can see which evidence supports the assessment and which files or prose satisfy the requested change.\n\nConstraints:\n- preserve public wire values and tenant boundaries\n- cover cancellation and retry behavior\n- avoid generated code and unrelated cleanup\n- include a rollback trigger that an on-call engineer can measure\n\nThis is a fresh workstream for the release, so derive everything from the repository and the context here.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Unify the LongbowSpruceDaemonService validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Delta: projects/longbow/services/ledger/replay.go の LongbowAmberFilterService で、Playwright の flow に断続的な問題が起きています。 責務を分離して重複をなくし、API、wire value、順序、観測可能な動作は変えないでください。\n\n制約:\n- Playwright を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は LongbowAmberFilterService のみ","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"ja"}
{"prompt":"LongbowVelaDrawerCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Ember: Two deliverables are holding up LongbowCloudReconcilerCoordinator. First, find the unknown cause of a feature flag whose default differs between environments. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/longbow/apps/console/routes/usage.svelte, which follows React 19 conventions and currently suffers from a feature flag whose default differs between environments. Leave generated files and vendored code alone.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Animate the LongbowBasilRunnerStore drawer","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Frost: Compare LongbowGarnetModalService's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"# projects/longbow/internal/auth/refresh.go\n[worker.longbowsableparserflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.longbowsableparserflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.longbowsableparserflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.LongbowSableParserFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-52118\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/longbow/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":"LongbowOspreyJobCoordinator: correct, then document","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Trace LongbowBasilRunnerService's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Outline a safer LongbowFlintTimelineService cutover","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Draft LongbowRavenSessionStore's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Garnet: PM is preparing the LongbowCraneWorkspaceService rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowCraneWorkspaceService\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Please turn LongbowCopperBridgeFlow's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current LongbowCedarPolicyService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowCedarPolicyService\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"The LongbowVelaDrawerStore surface in projects/longbow/workers/thumbnail/consumer.ex 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":"Harbor: // projects/longbow/apps/console/routes/usage.svelte\nfinal class LongbowAtlasSearchFlowCoordinator {\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 LongbowAtlasSearchFlow; 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":"We expect LongbowPrismCacheStore to outgrow its current Core Data arrangement next quarter, but changing everything at once would be risky. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing Core Data deployment\n- keep the work scoped to LongbowPrismCacheStore and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"A previously stable test around LongbowFernSnapshotStore 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":"LongbowOrbitSyncCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Since the last release, LongbowSlateEditorService has shown a feature flag whose default differs between environments; nobody on the team can reproduce it reliably on a laptop. Trace task lifetime, cursor advancement, and durable acknowledgment across reconnects; produce a defensible root cause and the smallest experiment that would falsify it.\n\nConstraints:\n- leave generated files and vendored code alone\n- stay compatible with the existing React 19 deployment\n- keep the work scoped to LongbowSlateEditorService and its direct tests\n\nThe relevant code crosses billing, Elixir, Android. Prefer evidence from the repository and make any assumption explicit.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"LongbowAcornWidgetStore's staging timeout is already known to be wrong: change the single projects/longbow/internal/auth/refresh.go value from 15 to 30 seconds and leave production alone.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Iris: Ticket OPS-52140: retire the legacy replay path for LongbowMosaicGridFlow\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 LongbowMosaicGridFlow 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":"Em projects/longbow/cmd/exporter/main.py, o LongbowMapleQueueStore tem um problema intermitente no fluxo de Redis Streams. Separe responsabilidades e remova duplicação sem mudar API, wire values, ordem ou comportamento observável.\n\nRestrições:\n- continuar com Redis Streams\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao LongbowMapleQueueStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"pt"}
{"prompt":"Trace LongbowGarnetModalStore's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-52148: finish the compact LongbowAcornWidgetFlow filter experience\n\nRoute: /catalog/search\nSource: projects/longbow/infra/modules/edge/main.tf\nFramework: Playwright\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible LongbowAcornWidgetFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Juniper: Ticket OPS-52149: retire the legacy replay path for LongbowQuartzPlayerFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nTurn the artifact into a reversible LongbowQuartzPlayerFlow 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":"Two asks around LongbowBasilRunnerCoordinator: (1) separate LongbowBasilRunnerCoordinator's policy from transport without behavior changes; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Kestrel: The public surface of LongbowTideWorkerStore is frozen, but its internal ownership in projects/longbow/services/ledger/replay.go is difficult to test and even harder to change safely. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowTideWorkerStore\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android 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":"LongbowBeaconStoreCoordinator: polish the last piece","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Is there a cleaner way to separate LongbowSlateEditorStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Remove LongbowSableParserService's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Lumen: Two asks around LongbowEchoRegistryCoordinator: (1) separate LongbowEchoRegistryCoordinator's policy from transport without behavior changes; (2) capture the contract and rollback note for consumers. Leave generated files and vendored code alone, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"For LongbowSpruceDaemonCoordinator, lay out a staged migration for LongbowSpruceDaemonCoordinator; once that is complete, also add the visible loading and offline states. Work from projects/longbow/packages/api/openapi.yaml, stay with Terraform, and leave generated files and vendored code alone. Keep the two outcomes separately reviewable.","purpose":"planning","secondary":"frontendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"LongbowAtlasSearchCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Maple: The LongbowFrostPanelFlow 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":"LongbowGarnetModalCoordinator: ship, then assess","purpose":"frontendImpl","secondary":"review","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"diff --git a/projects/longbow/ui/settings/PrivacyPane.tsx b/projects/longbow/ui/settings/PrivacyPane.tsx\nindex 62d71aa..90f3c1e 100644\n--- a/projects/longbow/ui/settings/PrivacyPane.tsx\n+++ b/projects/longbow/ui/settings/PrivacyPane.tsx\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is LongbowRainfallDBCoordinator's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"// projects/longbow/src/sync/reconcile.ts\nfinal class LongbowCoralUploadFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate LongbowCoralUploadFlow'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":"LongbowKiteSchedulerCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Nimbus: // projects/longbow/lib/codec/frame.cc\nfinal class LongbowNimbusFormFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate LongbowNimbusFormFlow'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":"LongbowMosaicGridStore 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.6,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-52152: retire the legacy replay path for LongbowFernSnapshotCoordinator\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 LongbowFernSnapshotCoordinator 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":"LongbowLumenChartStore est-il sûr ?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"fr"}
{"prompt":"Incident timeline — INC-52142\n\n08:02 deploy LongbowIrisBatchFlow 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 LongbowIrisBatchFlow 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":"The behavior of LongbowNovaPickerStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/longbow/cmd/exporter/main.py. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- leave generated files and vendored code alone\n- retain the current Redis Streams operational envelope\n\nThis repository spans billing, Elixir, Android; use its existing conventions rather than importing a new abstraction.\n\nProduce durable prose rather than a code assessment or implementation change.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current LongbowOspreyJobStore design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside LongbowOspreyJobStore\n- leave generated files and vendored code alone\n\nSeveral teams work in this billing, Elixir, Android monorepo, so keep ownership and handoff points understandable in a small review.\n\nReturn an assessment of the existing artifact; only quote enough to make the walkthrough understandable.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-52134\n\n08:02 deploy LongbowDriftConsoleFlow 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 LongbowDriftConsoleFlow, 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":"LongbowDriftConsoleCoordinator: sort out the rough edge","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"En projects/longbow/services/ledger/replay.go, LongbowLedgerGateService tiene un problema intermitente en el flujo de Playwright. Sigue queue, scheduler y cancelación, compara hipótesis y encuentra la causa antes de proponer cambios.\n\nRestricciones:\n- seguir con Playwright\n- conservar compatibilidad y cancelación\n- limitar el cambio a LongbowLedgerGateService Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con Playwright alrededor de LongbowLedgerGateService.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"es"}
{"prompt":"Test Suite 'LongbowAmberFilterFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[LongbowAmberFilterFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/longbow/services/ledger/replay.go:144: error: -[LongbowAmberFilterFlowTests 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 '-[LongbowAmberFilterFlowTests 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 LongbowAmberFilterFlow'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":"LongbowDeltaCanvasCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"LongbowNimbusFormCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Milestones for replacing LongbowMicaProfileStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Opal: The minimum supported Core Data version in projects/longbow/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":"Find LongbowNimbusFormStore's duplicate retry source","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Prism: projects/longbow/apps/console/routes/usage.svelte の LongbowSlateEditorFlow で、React 19 の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- React 19 を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は LongbowSlateEditorFlow のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Rename LongbowSpruceDaemonStore's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
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"}
data/round2-14.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "our checkpoint restart produces wrong results but only for jobs restarted after more than 48 hours:\n\ncheckpoint written at step 412000, size 8.1 TB\nrestart at step 412000, continues to step 500000\nvalidation against a continuous run: max relative difference 4.1e-3 (tolerance 1e-9)\n\nthe checkpoint stores the state arrays and the RNG seed but not the RNG stream position, and the thermostat's random forces resume from the seed rather than from where they were\n\nthe relevant part of the checkpoint code:\n\n ! checkpoint.f90\n write(unit) step, n_atoms\n write(unit) positions, velocities\n write(unit) rng_seed\n ! rng_pos declared, never written <- compiler warns about it, we've ignored that for years\n\n ! thermostat.f90, on restart\n call random_seed(put=rng_seed) ! stream restarts from the beginning\n\nvalidation runs so far:\n restart after 6h max rel diff 2.1e-11 (looks fine)\n restart after 24h max rel diff 8.8e-6\n restart after 48h max rel diff 4.1e-3\n\nthe two papers under discussion both used runs restarted at least twice", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "the checkpoint writer and reader have drifted apart across three format versions:\n\n! checkpoint.f90 — writer\nwrite(unit) step, n_atoms, positions, velocities, seed\n\n! checkpoint.f90 — reader, with version sniffing\nread(unit) step, n_atoms\nif (n_atoms > 0 .and. n_atoms < HUGE_N) then\n read(unit) positions, velocities, seed ! v2\nelse\n rewind(unit); read(unit) step, positions, velocities ! v1, no seed\nend if\n\nversion detection by whether a field looks plausible, no magic number, no version field, and v3 adds the RNG position we need for correct restarts", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "HRIS special cases into configuration", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "a real checkpoint format with a version field", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "job adverts stopped syncing to one job board and their support says they see nothing:\n\nPOST https://partner.jobboard.example/v2/postings\n → 200 OK {\"accepted\": true, \"id\": \"jb_88412\"}\n\nour sync log:\n posted 412 adverts, 412 accepted, 0 errors\n\ntheir side:\n \"we have received 0 postings from your account since 21 July\"\n\nwe changed the partner API key on 21 July; the old key still returns 200 with an accepted body but their system discards the postings, which their docs describe in a footnote as \"deprecated key behaviour\"", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "our receipt rendering path, which is why the cheap tills fall over:\n\nfun renderToBitmap(receipt: Receipt): Bitmap {\n val height = receipt.lines.size * LINE_HEIGHT_PX // 203dpi, ~34px per line\n val bmp = Bitmap.createBitmap(WIDTH_PX, height, Bitmap.Config.ARGB_8888)\n val canvas = Canvas(bmp)\n receipt.lines.forEachIndexed { i, line -> canvas.drawText(line, 0f, (i * LINE_HEIGHT_PX).toFloat(), paint) }\n return bmp\n}\n\nARGB_8888 at 576 pixels wide, a 60-line receipt is about 4.7MB, a 500-line stocktake report is 40MB, and the printer takes a monochrome bitmap anyway", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "the HRIS field mapping lives in YAML with per-customer special cases in code:\n\n# mappings/acme.yaml\nfirst_name: givenName\nstart_date: startDate # format: YYYY-MM-DD\n\n# mappings/globex.yaml\nfirst_name: fname\nstart_date: start # format: DD/MM/YYYY <- handled by an if in the pusher\n\n// pusher.ts\nif (customer === 'globex') payload.start = formatUk(offer.startDate)\nif (customer === 'initech') payload.employee_id = padLeft(offer.id, 8)\nif (customer === 'umbrella') delete payload.middle_name\n\nnine customers, four with code special cases, and adding a tenth means a deploy", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "a migration archived forty thousand applications at one customer because their talent pool records had never been touched since creation, and unarchiving them is a click each in the product. i want the recovery planned properly — how we identify exactly which records we archived, how we put them back without a script that could touch anyone else's data, and what we change so a migration can't do this again", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "HRIS integration guide was written for one customer and is now used for nine, four of whom have special cases living in if-statements. write the guide that reflects reality, and separately list every special case that should be configuration so we can stop deploying to onboard a customer keep it concrete — file names and line numbers are more use than principles here.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "offline banner with today's total", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "what makes an application \"active\"?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "simulation is one four-thousand-line module and only one person can work on it, which is now the binding constraint on everything else in the group's list. before splitting it i'd like agreement on the seams — I/O, decomposition, physics, output — and on how we prove the split changed nothing, given our only test is a stored trajectory", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "job adverts stopped reaching a job board three weeks ago while their API kept returning 200 with an accepted body, which our sync treats as success. work out what we should have been checking, and whether any other partner integration has the same shape of silent failure nobody has trusted this code for about a year, which is part of the problem.", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "interview scheduling emails go out with the wrong timezone for about one candidate in twenty:\n\ninterview i_4471\n scheduled_at (db, timestamptz): 2026-08-03 14:00:00+00\n interviewer timezone: Europe/Berlin\n candidate timezone: America/New_York (from their profile)\n email to candidate said: 3 August, 14:00 (your local time)\n actual time in New York: 10:00\n\nthe template formats with the interviewer's timezone but labels it as the candidate's, and only candidates whose profile timezone differs from the interviewer's notice", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "an MPI job hangs at the same point every time on more than 512 ranks:\n\n[rank 0] entering collective: MPI_Allreduce (comm=MPI_COMM_WORLD, count=4194304, MPI_DOUBLE)\n[rank 1] entering collective: MPI_Allreduce\n...\n[rank 511] entering collective: MPI_Allreduce\n[rank 512] entering collective: MPI_Bcast (comm=MPI_COMM_WORLD, count=1, MPI_INT)\n[rank 513] entering collective: MPI_Bcast\n...\n<no further output, job killed by the scheduler at the 24h wall clock>\n\nranks 512 and above take a different branch that broadcasts a convergence flag before the reduction, and the branch depends on a value computed from the local domain size", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "stock counts drift in stores that use the handheld scanners, about 0.3% of lines a week:\n\nscan event sku=SKU-4471 qty=1 device=hh_881 at=11:02:14.114 synced_at=11:02:19\nscan event sku=SKU-4471 qty=1 device=hh_881 at=11:02:14.118 synced_at=11:02:19\nstock movement sku=SKU-4471 delta=-1 source=scan at=11:02:19\nstock movement sku=SKU-4471 delta=-1 source=scan at=11:02:19\n\nthe scanner debounces a double trigger in firmware at 200ms, these are 4ms apart, and each scan gets a device-local id that the backend uses for idempotency — but the id is a counter that resets when the handheld is docked", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "three places decide whether an application is \"active\" and they disagree:\n\n// api/pipeline.ts\nconst active = (a: Application) => !['rejected', 'withdrawn', 'archived'].includes(a.stage)\n\n// jobs/nurture.ts\nconst active = (a: Application) => a.stage === 'pool' || a.stage === 'applied'\n\n-- reports/active_candidates.sql\nWHERE a.stage NOT IN ('rejected', 'withdrawn') AND a.archived_at IS NULL\n\nthe report includes archived-by-migration records that have archived_at set but stage still 'pool' for some rows, because the migration set both and an earlier one set only stage", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "careers page says \"Sorry, no jobs founds\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "payment buttons need to be 72dp", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "pipeline filters should live in the URL", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "is the scan idempotency key unique enough?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "checkpoint restarts are silently wrong for long jobs because the RNG stream position isn't saved, and two published papers used runs that were restarted. i need the plan: how we determine which results are affected, what we tell the group and the journals if any are, and how the format changes so this class of error is impossible rather than merely fixed", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.95, "slice": "core", "lang": "en"}
{"prompt": "offline card payments are now contractual with limits, automatic retransmission and same-day manager reporting, none of which we have. work through what that means for the till, the backend and the store manager's tooling, and be explicit about which parts need the payment vendor's cooperation rather than just ours we've been burned by guessing at this before, so evidence over instinct please.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "simulation module split needs the seams agreed before anyone moves a line, and then the I/O layer extracted first because it's the least entangled. do both, and keep the stored-trajectory test passing at every step", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "what does the till do with an offline voucher that is declined the next morning", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "por favor, revisa la consulta que alimenta el panel de reclutamiento antes de que la subamos:\n\nSELECT j.id, j.title,\n count(a.*) FILTER (WHERE a.stage = 'applied') AS applied,\n count(a.*) FILTER (WHERE a.stage = 'interview') AS interviewing,\n (SELECT count(*) FROM interviews i WHERE i.job_id = j.id AND i.starts_at > now()) AS upcoming,\n (SELECT avg(EXTRACT(epoch FROM (a2.hired_at - a2.created_at))/86400)\n FROM applications a2 WHERE a2.job_id = j.id AND a2.hired_at IS NOT NULL) AS avg_days_to_hire\nFROM jobs j\nLEFT JOIN applications a ON a.job_id = j.id\nWHERE j.tenant_id = $1 AND j.status = 'open'\nGROUP BY j.id, j.title;\n\nel inquilino más grande tiene 4.100 vacantes abiertas y 8,2 millones de candidaturas", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "es"}
{"prompt": "changelog for the POS release, which stores will read on their tills:\n\n41c9e0b fix(print): receipts render in bands rather than one bitmap, fixing crashes on 1GB tills\n88f21c0 fix(payments): terminal client retries once on a read timeout before falling back to offline\nc0aa774 feat(offline): offline vouchers now carry a reference the till can reconcile automatically\n2e91b45 fix(scan): scan idempotency now uses a device-persistent id rather than a resetting counter\naa30f19 feat(stock): stocktake reports print in landscape on the wide printers\n9c1d004 chore: minimum android is now 11\n4410bb7 fix(ui): the numeric keypad no longer accepts a leading zero on quantities\nb77e910 feat(returns): returns without a receipt require a manager PIN\n\nour readers are store managers, not engineers; two of these change what staff do at the till", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "unsere Mandantenprüfung ist an vierzehn Stellen unterschiedlich implementiert:\n\n// api/jobs.ts\nwhere: { tenantId: session.tenantId }\n\n// api/applications.ts\nwhere: { job: { tenantId: session.tenantId } }\n\n// api/reports.ts\nconst rows = await prisma.$queryRaw`SELECT ... WHERE tenant_id = ${session.tenantId}`\n\n// jobs/nurture.ts\n// keine Prüfung – der Job läuft für alle Mandanten und filtert nach Stage\n\nvierzehn Stellen, drei Muster, und eine Stelle ohne Prüfung; ich hätte gern eine Durchsetzung, die man nicht vergessen kann", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "de"}
{"prompt": "design spec for the recruiter pipeline board, which recruiters have open all day:\n\nPipeline board\n- Columns per stage, cards per candidate, virtualised — the largest tenant has 4,000 candidates in one job.\n- Card shows name, current stage age, source, and a flag if an interview is scheduled within 24 hours.\n- Drag between columns moves the stage optimistically, with a toast that can undo for ten seconds.\n- Bulk select with shift-click, then a bulk action bar; every bulk action states how many candidates it affects.\n- Filters: source, stage age, interviewer, tag. Filters live in the URL so recruiters can share a view.\n- Keyboard: arrow keys move between cards, enter opens, m moves stage via a menu — recruiters asked for this.\n- An archived candidate must be visibly distinct rather than absent, because \"where did they go\" is our top support question.\n- Everything must stay responsive with 4,000 cards and a websocket delivering updates from other recruiters.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "terminal read timeout to 10s with one retry", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "stage needs an indicator besides colour", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "apply modal traps focus with no escape", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "one active-application predicate", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "doc comments on the public jobs API", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "why does the 512-rank job hang?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "applications lost at the morning spike", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "till screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "tenant scoping is done by hand in fourteen places with three patterns and one omission, and we have no test that would catch a fifteenth. i want a position on enforcement — row-level security, a repository layer, or something else — that survives our transaction-scoped pooler and the reports that use raw SQL", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether a restarted run can differ from a continuous one in a way that matters, and two papers depend on the answer. read the checkpoint writer, the reader and the thermostat's use of the RNG, and tell me exactly what diverges and by how much on a realistic run whatever you find, write it somewhere the next person will actually look.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "scan idempotency key is device id plus a device-local counter that resets when the handheld is docked, held in a one-hour cache, across four hundred devices. work out how often two different scans can collide on that key, and whether the stock drift we see is consistent with that rate i'm not attached to the current approach if there's an obviously better one.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "before we touch the checkpoint format i want the failure modes written down — restart on a different rank count, a changed thermostat, a truncated file — and then the versioned header implemented against that analysis", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like an honest read of whether our OpenMP reduction can produce different totals for the same input on the same machine, and if it can, the change that makes it deterministic without costing more than a few percent", "purpose": "review", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "recruiter app ignores the tokens and uses stage colour as the only stage indicator. bring it onto the tokens with a non-colour indicator, and tell me whether the card height changes enough to affect how many fit on a laptop screen", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "ATS background jobs each construct their own prisma client, which is a meaningful share of the connections at 09:00. share one, and tell me which jobs were relying on their own transaction isolation before i approve it", "purpose": "quickFix", "secondary": "review", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "payment vendors behind one interface", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "stock drifts on handheld scans", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "an HPC customer's security team asked six questions about credentials, shared filesystems, telemetry and job isolation, and our honest answers include a couple of \"not currently\". write the document from the code, mark those clearly, and give each one a remediation note rather than leaving it hanging this is the third time it's bitten us and i'd like it to be the last.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "checkpoint design note assumes restarts happen on the same rank count and that the RNG is reseeded from the step, neither of which is true today. read it against the code and tell me which of its other assumptions have quietly stopped holding as our jobs got longer context if it helps: this has been open since before i joined the team.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "three payment vendors have three client shapes, three error taxonomies and three copies of the offline voucher logic with slightly different conditions. put them behind one interface with one offline policy, keeping each vendor's on-the-wire behaviour exactly as it is, and make the differences visible in configuration rather than in branches", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "pipeline board is what recruiters have open all day and it currently renders four thousand cards eagerly and loses their filters on refresh. rebuild it to the spec — virtualised, filters in the URL, keyboard navigation, archived candidates visible rather than absent — without changing the drag interaction people are used to assume whoever picks it up next has no context beyond what you write.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our careers-site API, which twelve customers embed in their own sites from a README:\n\nGET /v1/public/jobs?tenant=&location=&department=&remote=\n returns open jobs only; a job closed while a candidate is on the page 404s on apply\n ordering is by posted_at desc with no tie-break, so equal timestamps reorder between requests\n the description field is HTML we sanitise on write, not on read, and old records predate the sanitiser\nPOST /v1/public/applications\n multipart with a CV up to 10MB; larger uploads fail with a generic 400\n duplicate applications to the same job are accepted silently and appear twice to the recruiter\n the response is 201 with an application id that is not shown to the candidate anywhere\n\nwrite the reference for customers embedding this, and be explicit about the duplicate behaviour", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "the simulation group's list, with a paper deadline in eight weeks:\n\n- fix the checkpoint RNG position, which may invalidate results in the last two papers\n- decide on -ffast-math, which costs 18% if we remove it\n- fixed-order reduction, which costs 4% and a kernel rewrite\n- the 512-rank hang, which blocks the largest runs entirely\n- split the 4,000-line module so more than one person can work on it\n- job scripts that don't waste 88% of each node\n\none Fortran engineer, and the deadline is real but the correctness questions are older", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "HRIS field mapping is YAML plus four customer names hardcoded in the pusher, so onboarding a tenth customer means a deploy. move the special cases into the mapping format itself, keep every current customer's payload byte-identical, and add the test that proves it for each tell me if this is the wrong shape entirely, i won't be offended.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "a 512-rank job hangs at the same collective every time and the branch that broadcasts a convergence flag looks like the culprit. confirm it, then restructure the collectives so all ranks agree on what they're calling", "purpose": "debugging", "secondary": "refactor", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "job list widget should degrade to plain server-rendered HTML when scripts are blocked", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "our runbook for the 09:00 application spike is \"watch the dashboard\". what the team actually does:\n\n- job adverts go out by email at 09:00 and the apply endpoint takes ten times its normal load for about twenty minutes\n- the first symptom is connection pool exhaustion, which shows as 500s on apply and nothing else\n- scaling the app up makes it worse, because each instance takes ten more connections\n- the actual mitigation is scaling down to 20 instances, which nobody believes until they try it\n- pgbouncer exists in staging and has never been enabled in production\n- if applications are lost rather than delayed, they are recoverable from the email bounce log, painfully\n\nwrite the runbook, and mark clearly that scaling up is the wrong instinct", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "the retailer's requirements for offline payments, which are now contractual:\n\n\"The point of sale shall continue to accept card payments when the payment terminal is temporarily unreachable, subject to a configurable per-store limit on the total value of offline transactions. Offline transactions shall be transmitted for authorisation within 15 minutes of connectivity being restored, without staff intervention. Declined offline transactions shall be reported to the store manager the same day. The system shall not permit offline acceptance for transactions above a configurable value.\"\n\nwe have no limits, no automatic retransmission except on restart, and no manager-facing report. i want the plan by contractual exposure", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "a walkthrough of how a scan becomes a stock movement would help before i touch idempotency", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "HRIS integration guide needs writing and i expect it will surface behaviours we should change rather than document — the silent failure after three retries especially. write the guide, and give me that list", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "careers widget documentation has to exist for the customers embedding it, and while writing it please confirm whether duplicate applications really are accepted silently, because support believes they're rejected", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "offline payments runbook for store managers should exist, and the till should stop printing vouchers past a sensible daily limit. write the runbook, then add the limit with a configurable default", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "interview emails show the wrong local time for candidates in other timezones, which looks like the formatter using the interviewer's zone. confirm that, then fix it and work out how many past emails were wrong so we can decide whether to apologise i've already spent an afternoon on it and got nowhere useful.", "purpose": "debugging", "secondary": "writing", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "is our job efficiency really 12%, or is the accounting measuring something else", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does the apply endpoint make once it has returned a 201 to the candidate", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "simulation writes trajectory output through three routines depending on format, and two of them buffer differently so a killed job loses a different amount of data. unify them behind one writer, and tell me which format's flush behaviour we should adopt given jobs are killed by the scheduler routinely this has come up in three separate reviews now and never gets done.", "purpose": "refactor", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "job adverts should be verified by reading the posting back rather than trusting a 200, and we should decide first what we do when the read-back disagrees — retry, alert, or mark the advert failed. settle that, then implement flag anything you'd want to change before doing it rather than after.", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "candidate applications vanish between the form and the database, maybe five a day:\n\nPrismaClientUnknownRequestError: \nInvalid `prisma.application.create()` invocation:\nError occurred during query execution:\nConnectorError(ConnectorError { user_facing_error: None, kind: QueryError(PostgresError { code: \"53300\", message: \"remaining connection slots are reserved for non-replication superuser connections\" }) })\n at Ai.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:121:6412)\n at async POST (/app/app/api/apply/route.ts:88:22)\n\nconnection pool: 10 per instance, 40 instances behind the autoscaler, postgres max_connections 100\nthe apply endpoint is the only one that spikes, because job ads go out by email at 09:00", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "so our simulation gives different answers on the new cluster and i can't tell which is right:\n\n old cluster (gcc 11, -O2, AVX2): total energy = -1042.884112 Ha\n new cluster (gcc 14, -O3, AVX512): total energy = -1042.884109 Ha\n reference (published): total energy = -1042.884110 Ha\n\ncompiler flags on the new cluster: -O3 -march=native -ffast-math -funroll-loops\ncompiler flags on the old cluster: -O2 -march=haswell\n\nthe kernel sums a 4-million-element array of pair interactions in a plain loop, and the reduction order differs between the two builds", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "tills stop taking card payments in one store every afternoon, always around the same time:\n\n14:02:11.114 [pos-04] payment start amount=1240 currency=GBP\n14:02:11.882 [pos-04] terminal connect 192.168.10.44:9100\n14:02:41.902 [pos-04] terminal read timeout after 30s\n14:02:41.905 [pos-04] payment failed, offline voucher printed\n14:02:44.001 [pos-04] terminal connect 192.168.10.44:9100\n14:03:14.020 [pos-04] terminal read timeout after 30s\n\nstore wifi shows a channel change at 14:00 daily, which is when the bakery ovens come on, and the terminals are on wifi while the tills are wired", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "seit dem letzten Deploy verschwinden Bewerbungen aus dem Talent-Pool, aber nur bei einem Kunden:\n\nSELECT count(*) FROM applications WHERE tenant_id = 'acme' AND stage = 'pool';\n vor dem Deploy: 41.882\n nach dem Deploy: 1.204\n\nMigration aus dem Deploy:\n UPDATE applications SET stage = 'archived'\n WHERE stage = 'pool' AND updated_at < now() - interval '180 days';\n\nbei diesem Kunden werden Bewerbungen im Pool nicht angefasst, solange niemand sie öffnet, also ist updated_at das Erstellungsdatum; bei allen anderen Kunden läuft ein Nurturing-Job, der die Datensätze regelmäßig berührt", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "ok so the POS app crashes on a specific till model when printing a receipt with more than about forty lines:\n\nFATAL EXCEPTION: main\nProcess: io.lumenpos.till, PID: 4412\njava.lang.OutOfMemoryError: Failed to allocate a 41943040 byte allocation with 12582912 free bytes\n\tat android.graphics.Bitmap.nativeCreate(Native Method)\n\tat io.lumenpos.print.ReceiptRenderer.renderToBitmap(ReceiptRenderer.kt:141)\n\tat io.lumenpos.print.PrintJob.execute(PrintJob.kt:88)\n\nwe render the whole receipt into one bitmap at 203dpi before sending it to the printer, and these tills have 1GB of RAM", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "could you look at the pooling before i sign this off? the 09:00 spike is what worries me:\n\nexport const prisma = new PrismaClient({\n datasources: { db: { url: process.env.DATABASE_URL } },\n})\n\n// route.ts\nexport async function POST(req: Request) {\n const body = await req.json()\n const application = await prisma.application.create({ data: { ...body } })\n await sendConfirmationEmail(application) // awaited, 400-800ms\n await notifyRecruiters(application) // awaited, fans out to up to 12 recipients\n return Response.json({ id: application.id })\n}\n\nforty instances, ten connections each, postgres allows a hundred, and the two awaits hold the request open for over a second", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "honestly the reduction kernel, which is where our numbers differ between clusters:\n\nsubroutine pair_energy(n, r, q, energy)\n integer, intent(in) :: n\n real(8), intent(in) :: r(3,n), q(n)\n real(8), intent(out) :: energy\n integer :: i, j\n energy = 0.0d0\n !$omp parallel do reduction(+:energy) private(j)\n do i = 1, n\n do j = i+1, n\n energy = energy + q(i)*q(j)/norm2(r(:,i) - r(:,j))\n end do\n end do\nend subroutine\n\nbuilt with -ffast-math on the new cluster, thread count differs between runs, and the result is quoted to ten significant figures in our papers", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "right, the idempotency handling for handheld scans, which i think is behind the stock drift:\n\n@PostMapping(\"/v1/scans\")\npublic ResponseEntity<Void> scan(@RequestBody ScanBatch batch) {\n for (Scan s : batch.scans()) {\n String key = s.deviceId() + \":\" + s.localId();\n if (seen.putIfAbsent(key, Boolean.TRUE) == null) {\n stock.apply(s.sku(), -s.qty(), \"scan\");\n }\n }\n return ResponseEntity.accepted().build();\n}\n\n`seen` is a Caffeine cache with a one hour expiry, localId is a device counter that resets on docking, and there are 400 handhelds across the estate", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "quick one — the checkpoint format's design note, written when jobs ran for eight hours rather than three weeks:\n\n## Checkpoint contents\nState arrays, the current step, the input parameters and the RNG seed. Written every 10,000 steps to the parallel filesystem.\n\n## Assumptions\n- A restart continues a run that would otherwise have been identical.\n- The RNG is reseeded deterministically from the seed and the step.\n- Checkpoints are read back on the same number of ranks.\n\n## Not covered\nRestarting on a different rank count. Changing the thermostat between restarts. Reproducibility across compilers.\n\nwe now restart on different rank counts routinely, and the RNG is not reseeded from the step at all", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "fyi the migration that archived a customer's talent pool, which i'd like reviewed before we write the recovery:\n\n-- 20260722_archive_stale_pool.sql\nUPDATE applications\n SET stage = 'archived', archived_at = now()\n WHERE stage = 'pool'\n AND updated_at < now() - interval '180 days';\n\n-- rollback (as written in the migration file)\n-- none\n\napplications has no history table; archived_at is the only trace; and updated_at means \"last touched by anything\", which for one tenant is the creation date because they don't run the nurturing job", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "heads up: the job scheduler script we hand to researchers, which i suspect is why jobs sit in the queue:\n\n#!/bin/bash\n#SBATCH --nodes=64\n#SBATCH --ntasks-per-node=8\n#SBATCH --cpus-per-task=16\n#SBATCH --time=24:00:00\n#SBATCH --exclusive\n#SBATCH --mem=0\n\nexport OMP_NUM_THREADS=16\nexport OMP_PLACES=cores\nsrun ./simulate input.dat\n\nthe cluster has 128 cores per node, our job asks for 8 tasks × 16 threads = 128, exclusive plus mem=0 takes the whole node, and the queue's backfill window is four hours", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the archived applications, which we need to turn into a customer explanation:\n\n- a migration archived applications in the talent pool that hadn't been updated in 180 days\n- for most customers a nurturing job touches these records, so almost nothing was archived\n- for one customer the nurturing job is disabled, so updated_at was the creation date and 40,000 records were archived\n- the records are not deleted; they're in the archived stage and can be moved back\n- moving them back individually is a click each; there is no bulk unarchive in the product\n- we can do it with a script, but archived_at is the only evidence of which records we touched\n\nwrite the customer explanation and the internal note about what we're doing to restore them", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from the till outage, and the retailer wants a written explanation:\n\n14:02 store 44 reports card payments failing on all six tills\n14:20 other stores unaffected; store 44's terminals are on wifi, tills are wired\n14:35 store wifi logs show a channel change at 14:00, coinciding with the bakery ovens starting\n15:10 terminals moved to the wired network as a workaround, payments resume\n16:00 root cause: the terminals lose association during the channel change and our client has a 30 second read timeout with no retry\n17:30 during the outage, staff used offline vouchers for 412 transactions, of which 8 were later declined\n\nthe retailer's question is why a wifi hiccup takes down payments at all when the tills are wired", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "as notas da reunião sobre reprodutibilidade, para transformar em documento de decisão:\n\n- os resultados diferem entre o cluster antigo e o novo na décima casa decimal\n- a causa provável é -ffast-math combinada com uma redução OpenMP cuja ordem varia com o número de threads\n- publicámos valores com dez algarismos significativos em dois artigos\n- opções: fixar a ordem da redução, remover -ffast-math, ou passar a publicar com incerteza declarada\n- remover -ffast-math custa cerca de 18% de desempenho segundo o teste que fizemos\n- a ordem fixa custa cerca de 4% e obriga a reescrever o kernel\n\nescreve a nota de decisão com as opções, o custo de cada uma e uma recomendação para o grupo", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "pt"}
{"prompt": "small thing but the questions our new HPC customer's IT security team sent, which need answering as a document:\n\n\"What data does the job submission tool send to your servers, and can it operate fully offline? Where are user credentials stored on shared login nodes? Does your software write anything to a world-readable location? Can a user's job read another user's checkpoint data on the shared filesystem? How do you handle a job that exceeds its allocation — is it killed, and by whom? What telemetry do you collect from academic sites and can it be disabled?\"\n\nour honest answers are mixed at best; write the document from the code, and mark clearly which answers are \"not currently\" rather than presenting them as design decisions", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "社内向けに、レジ端末のオフライン運用手順が文書化されていません。現状は次の通りです:\n\n- カード端末が 30 秒応答しない場合、レジはオフラインバウチャーを印刷する（リトライはしない）\n- オフラインバウチャーは後で一括送信されるが、与信が通らない場合は店舗の損失になる\n- 一日あたりのオフライン上限は設定されておらず、先週は 412 件が積み上がった\n- レジ側のログはローカルにしか残らず、7 日で上書きされる\n- 店舗マネージャーはオフライン件数を確認する画面を持っていない\n- 復旧後の再送はレジの再起動時にのみ行われる\n\n設定例:\n\nterminal:\n read_timeout_ms: 30000\n retries: 0\n offline_voucher_limit: null\n\n店舗マネージャー向けの手順書として、また社内の開発者向けの注意点として、それぞれまとめてください\n\n先週のオフライン件数（店舗別、上位）:\n store 44 412 件 合計 £18,204 後日否認 8 件\n store 12 88 件 合計 £3,110 後日否認 1 件\n store 07 41 件 合計 £1,204 後日否認 0 件\n\n関連する設定とログ:\n\n terminal:\n read_timeout_ms: 30000\n retries: 0\n offline_voucher_limit: null\n resubmit_on: [\"app_start\"]\n\n 14:02:41 [pos-04] terminal read timeout after 30s\n 14:02:41 [pos-04] payment failed, offline voucher printed\n\n店舗マネージャーはこの数字をどこからも見られません", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "ja"}
{"prompt": "not urgent, but the ATS's integration guide for HR systems, written for one customer and now used by nine:\n\nwe push hires to the customer's HRIS on offer acceptance:\n POST {customer_endpoint}/employees with our own field names, mapped per customer in a YAML file\n retries: 3, then a support ticket is created and someone re-runs it by hand\n the mapping file lives in our repo, so a new field for one customer is a deploy\n four customers require a custom date format and two require a custom ID scheme\n nobody has documented which customer needs what; the YAML comments are the only record\n a failed push leaves the offer accepted in our system with no indication that the HRIS is out of sync\n\nwrite the integration guide, and separately list what should be configuration rather than code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "eslint and tsc on the ATS, gate goes on next sprint:\n\napp/api/apply/route.ts:88:22 - error TS2345: Argument of type 'unknown' is not assignable to parameter of type 'ApplicationCreateInput'\napp/lib/mail.ts:41:9 - warning: Promise returned in function argument where a void return was expected @typescript-eslint/no-misused-promises\napp/lib/tenant.ts:141:3 - error TS2532: Object is possibly 'undefined'\napp/components/PipelineBoard.tsx:212:5 - warning: React Hook useEffect has a missing dependency: 'tenantId'\napp/lib/dates.ts:22:11 - error TS2769: No overload matches this call (formatInTimeZone)\n\n3 errors, 2 warnings, and dates.ts is the file behind the timezone emails", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "compiler warnings from the simulation build, which we've been ignoring for years:\n\nsrc/pair.f90:141:22: warning: 'energy' may be used uninitialized [-Wmaybe-uninitialized]\nsrc/io.f90:88:5: warning: array 'buf' is used uninitialized [-Wuninitialized]\nsrc/thermostat.f90:41:9: warning: comparison of real values with == [-Wfloat-equal]\nsrc/checkpoint.f90:212:13: warning: unused variable 'rng_pos' [-Wunused-variable]\nsrc/main.f90:22:1: warning: obsolescent feature: COMMON block\n\n41 warnings total; checkpoint.f90's unused rng_pos is exactly the variable our restart bug is about", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "genuinely puzzled by this: the till app's config across store types, and only the small stores crash:\n\n# flagship stores\nprint:\n render_mode: banded\n band_height_px: 512\n bitmap_config: ALPHA_8\ndevice: { ram_mb: 4096, android: 13 }\n\n# small stores\nprint:\n render_mode: single\n band_height_px: null\n bitmap_config: ARGB_8888\ndevice: { ram_mb: 1024, android: 11 }\n\nbanded rendering was added for the flagship rollout and never enabled anywhere else\n\nand the crash rate per store type over the last month:\n\n flagship (4GB, android 13, banded) 0 crashes / 41,882 receipts\n standard (2GB, android 12, single) 14 crashes / 88,214 receipts\n small (1GB, android 11, single) 412 crashes / 21,004 receipts\n\nevery crash is the same OutOfMemoryError in renderToBitmap, and the receipts that trigger it are stocktake reports and long promotional receipts", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "pasted-context", "lang": "en"}
{"prompt": "slurm accounting for our group this month, and we're being asked why utilisation is low:\n\nJobID Nodes Elapsed CPUTime TotalCPU Efficiency\n881204 64 23:58:12 1536:00 184:12 11.9%\n881207 64 23:59:02 1536:00 201:44 13.1%\n881209 32 04:12:44 134:48 128:02 94.9%\n881211 64 23:58:44 1536:00 190:22 12.4%\n\nthe 64-node jobs request 8 tasks per node with 16 threads each on 128-core nodes, and the three long ones all hit the wall clock rather than converging", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "dependabot on the ATS, four open and one blocks the store submission:\n\nnext 15.1.0 → 15.4.2 (patch series; middleware behaviour changed for rewrites)\n@prisma/client 5.19 → 6.2 (major; connection pool defaults changed, `connection_limit` now per-process)\ndate-fns-tz 2.0.0 → 3.2.0 (major; formatInTimeZone signature changed)\nnodemailer 6.9.13 → 6.10.1 (patch)\n\nthe date-fns-tz major is the library our timezone bug is in, and the prisma major changes exactly the pooling behaviour we're fighting", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "les seuils d'alerte de la plateforme de recrutement, on nous réveille pour rien :\n\n- alert: ApplyErrorRate\n expr: rate(http_requests_total{route=\"/api/apply\",code=~\"5..\"}[5m]) > 0\n for: 1m\n labels: { severity: page }\n\n- alert: DbConnections\n expr: pg_stat_activity_count > 90\n for: 5m\n labels: { severity: ticket }\n\n- alert: SyncFailures\n expr: increase(partner_sync_failed_total[1h]) > 0\n for: 0m\n labels: { severity: ticket }\n\nen pratique : le taux d'erreur dépasse zéro tous les matins à 9h ; la saturation des connexions n'est qu'un ticket alors que c'est la cause ; et la synchronisation vers un job board renvoyait 200 tout en jetant nos annonces, donc aucune alerte n'a été déclenchée pendant trois semaines", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "fr"}
{"prompt": "this module does I/O, domain decomposition and the physics in one file, and every change touches all three:\n\nmodule simulate\n ! reads input.dat, including three formats we've supported over the years\n ! decides the domain decomposition from the rank count\n ! allocates the state arrays\n ! runs the integrator, calling the pair kernel and the thermostat\n ! writes checkpoints and trajectory output\n ! handles MPI setup and teardown\nend module\n\n4,000 lines of Fortran, one test that runs a tiny system and compares against a stored trajectory", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "quarter planning input, needs sequencing:\n\n- 40,000 applications were archived by a migration at one customer and unarchiving them is manual\n- the 09:00 spike takes the apply endpoint down most mornings and scaling up makes it worse\n- our simulation results differ between clusters in the tenth significant figure, and we publish ten\n- the POS crash on small tills affects 300 stores and the workaround is telling staff to print shorter receipts\n- checkpoint restarts are silently wrong for long jobs, which may affect published work\n- one Fortran engineer, two platform engineers, and the POS team is three people\n- there's an HPC customer procurement in october with a security questionnaire we can't currently pass", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, i want the thinking before code:\n\nATS-410 — Tenant isolation enforcement\nTenant scoping is applied by hand in fourteen places with three different patterns and at least one omission. The proposal is row-level security in postgres with the tenant set per connection, so a missing filter fails closed. Concerns: our connection pooler is transaction-scoped and the tenant would have to be set per transaction; some background jobs legitimately run across tenants; raw queries in reports bypass the ORM entirely; and we have no test that would catch a missing filter today, so we cannot prove the change is safe or that it was needed.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the till's payment screen, which cashiers use hundreds of times a day:\n\nPayment screen\n- Amount due in the largest type on the screen, unmissable from a metre away.\n- Payment method buttons at least 72dp tall, arranged so the most common method is under the thumb.\n- While waiting on the terminal: a progress state that names what is happening (\"waiting for card\", \"authorising\") rather than a generic spinner, with the elapsed seconds visible.\n- On timeout: an explicit choice — retry, or take the payment offline — never an automatic silent fallback.\n- Offline mode shows a persistent banner with the count and total value of offline transactions taken today.\n- Errors from the terminal are shown in the words the cashier needs (\"ask for another card\"), with the vendor code available on a long press for support.\n- The screen must be operable with gloves and must never require a precise tap.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings for the careers site widget, which our customers embed and are legally responsible for:\n\n1. The job list is a div soup with no list semantics and no headings, so screen reader users cannot navigate it.\n2. The filter controls are custom dropdowns with no keyboard support and no announced state.\n3. The apply form's file input is hidden behind a styled button with no label association.\n4. Required field errors appear only as red borders.\n5. The widget sets its own font size in px, overriding the host page's user scaling.\n6. Focus is trapped in the apply modal with no escape key handling.\n7. Colour contrast on the \"apply now\" button fails at 3.2:1 against our default background, which most customers keep.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the recruiter app actually uses:\n\ntokens:\n color.surface #FFFFFF / #0F1216\n color.text #0F1216 / #E8EDF3\n color.muted #626C76\n color.stage.new #0B62D6\n color.stage.offer #1A7F37\n color.stage.reject #B42318\n space 4/8/12/16/24/32, radius 6/10, focus 2px offset 2\n type: title 18/24, body 14/20, caption 12/16\n\nthe recruiter app: eight hardcoded colours including three blues, stage colour used as the only stage indicator on cards, focus removed on the card press target, paddings of 5/9/13/17, and a card title at 15px which is in no scale\n\nbring it onto the tokens and give stage a non-colour indicator on the card", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "pasted-context", "lang": "en"}
{"prompt": "banded rendering on the small tills", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "date-fns-tz major, before the timezone fix", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "enable pgbouncer in production", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "rotate the job board API key", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "en"}
{"prompt": "el correo de entrevista sale sin zona horaria", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "es"}
{"prompt": "our database connection settings versus what postgres allows:\n\napp instances (autoscaler): min 10, max 60\nprisma connection_limit: 10 (default, not set explicitly)\npostgres max_connections: 100\npostgres superuser_reserved_connections: 3\npgbouncer: deployed in staging only, transaction pooling\n\nat 09:00 the autoscaler goes to 40+ instances within two minutes because the apply endpoint's latency rises, which is itself caused by connection contention\n\nand what 09:00 looks like from the database side:\n\n 08:58 connections 41 apply p95 180ms instances 12\n 09:00 connections 96 apply p95 2.4s instances 18\n 09:02 connections 100 apply p95 timeout instances 41\n 09:06 connections 100 apply 500s 38% instances 60 (autoscaler ceiling)\n 09:22 connections 44 apply p95 210ms instances 14\n\npg_stat_activity during the spike is almost entirely idle-in-transaction, which is the two awaited emails inside the request", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "the HRIS integration spec from our largest customer, which we implement:\n\nPOST /api/v2/employees\n auth: OAuth2 client credentials, token valid 15 minutes, their token endpoint rate limits to 1/minute\n body: their field names, dates as YYYY-MM-DD, employee id assigned by them and returned in the response\n a duplicate push for the same offer must be idempotent on our `external_ref`, which they store but do not index\n they respond 202 and process asynchronously; failures arrive by email to a shared mailbox, not by callback\n a rejected employee record leaves the offer accepted on our side with no automatic reconciliation\n they have a nightly maintenance window during which everything returns 503\n we push about 400 hires a month, in bursts on the first of the month", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "HRIS pusher should reconcile nightly rather than leaving an offer accepted and unsynced", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "a short note on why the apply endpoint is moving to a queue, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "drop -ffast-math from the release build", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "DbConnections should page, not ticket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "cap prisma connections per instance", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "OMP_NUM_THREADS passt nicht zur Knotengröße", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "de"}
{"prompt": "uninitialised `energy` in pair.f90", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "archived candidates should be visible, not absent", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "求人ウィジェットの文字サイズが固定です", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "ja"}
{"prompt": "required errors are red borders only", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "terminal errors show vendor codes to cashiers", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "board drops frames past 2000 cards", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "split the 4000-line simulate module", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "un seul contrôle de locataire, partout", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "fr"}
{"prompt": "`stage` naming across the API", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "extract the offline voucher logic", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "inline `padLeft`, one caller", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "changelog for the POS release", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota aos clientes sobre as candidaturas arquivadas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "pt"}
{"prompt": "document the duplicate application behaviour", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the tenant isolation proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the checkpoint fix", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "can a restart change published results?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "¿por qué el 09:00 tumba el endpoint de solicitudes?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "walk me through the offer-to-HRIS push", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "card payments fail every afternoon in one store", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "warum unterscheiden sich die Ergebnisse je Cluster?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "de"}
{"prompt": "endpoint for a store's offline transactions", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "carry it on", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "less flaky", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick the order yourself", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo del cluster, continúa", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "es"}
{"prompt": "scanners again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "clean it as you go", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "same shape as last time", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "security answers for procurement", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "nothing that needs a deploy", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "give it a read", "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": "next on the list", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "09:00 application spike takes down the apply endpoint most mornings and every instinct the team has — scaling up, raising the pool size — makes it worse. i'd like the actual capacity model worked out, including whether pgbouncer solves it or just moves the queue, and what the endpoint should do when it genuinely can't accept an application", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "twelve customers embed our careers widget in their own sites and are legally responsible for its accessibility, which is currently poor enough to be a problem for them. write the integration documentation, including the accessibility characteristics they're inheriting and what they can configure, without pretending the widget is in better shape than it is if the answer is that it's fine as it is, that's a useful answer too.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "retailer wants a written explanation of why a wifi channel change in one store stopped card payments on wired tills, which is a fair question. write the incident report for their operations team — the terminal association, our timeout, the offline vouchers and the eight that were later declined — without hiding behind the word \"connectivity\"", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "runbook for the morning spike should say plainly that scaling up is the wrong instinct, because three separate people have made it worse that way. write it in the order someone would need at 09:05, with the connection maths spelled out so the advice is believable rather than folklore a rough ordering matters more to me than a complete answer right now.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "checkpoint format is detected by whether a field looks plausible, with no magic number and no version, and we now need to add the RNG position. give it a proper header with a version, keep reading both existing formats, and make an unrecognised file a clear error rather than a plausible misinterpretation i'd rather have the reasoning written down than a quick answer.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "payment screen currently falls back to offline silently on a timeout, which is how a store took four hundred vouchers without noticing. rebuild it to the spec — named progress states, an explicit choice on timeout, a persistent offline banner — and keep every tap target usable with gloves the sooner we know roughly how big this is, the better for planning.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "tenant isolation needs an approach decided and one concrete step taken. work through the options with me, then implement the repository-level scoping for the reports module, which is where the raw queries live", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "morning spike needs a capacity model and it needs the apply endpoint to stop dropping applications tomorrow. give me the model, then make the endpoint enqueue rather than write synchronously so a full pool delays rather than loses", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "our till's payment flow has three implementations depending on terminal vendor:\n\n// VendorA.kt — synchronous socket, 30s timeout, no retry\n// VendorB.kt — vendor SDK with callbacks, retries internally 3 times, reports only final failure\n// VendorC.kt — HTTP to a local bridge, 10s timeout, retries once, returns a different error taxonomy\n\nthe till's payment screen handles all three with a when(vendor) block in the view model, and offline voucher logic is duplicated in each branch with slightly different conditions", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "the schema we agreed for offline transactions, now it needs building on the till and the backend:\n\nCREATE TABLE offline_transactions (\n id uuid PRIMARY KEY,\n store_id uuid NOT NULL,\n till_id text NOT NULL,\n amount_cents bigint NOT NULL,\n currency char(3) NOT NULL,\n taken_at timestamptz NOT NULL,\n submitted_at timestamptz,\n outcome text CHECK (outcome IN ('approved','declined','expired')),\n card_ref text NOT NULL\n);\n\nthe till holds these locally until connectivity returns, submits within 15 minutes without staff action, enforces a per-store value limit and a per-transaction cap, and the store manager needs a same-day view of anything declined", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "unsere Offline-Zahlungen brauchen erst ein Konzept mit Limits und automatischer Nachübertragung und danach die Umsetzung der Limits auf der Kasse, weil das der vertraglich heikelste Teil ist", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "de"}
{"prompt": "escribe la guía del operador para el pico de las 09:00 y comprueba en el código si escalar instancias realmente empeora la situación, porque quiero poder demostrarlo y no solo afirmarlo", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "es"}
{"prompt": "active-application predicate exists three times and the report includes records the product hides. unify them, then document what each stage means, because \"archived\" apparently means two different things depending on which migration set it", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "receipt rendering should be banded everywhere rather than only on the flagship tills. make the change, and confirm from the store inventory how many devices are actually on the old configuration before we call it fixed", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.55, "slice": "mixed", "lang": "en"}
{"prompt": "fourteen tenant checks should become one mechanism, and i'd like to know first which of the fourteen is actually wrong rather than merely different. audit them, then unify", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "applications are lost rather than delayed during the morning spike, which the team assumes is the connection pool. verify that assumption end to end, then make the failure mode a delay rather than a loss", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "careers widget fails seven accessibility items and our customers carry the legal risk. fix them, and write the statement customers can put on their own accessibility pages", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "offline transaction limits need the semantics agreed — per store, per till, per day, and what happens at the boundary mid-transaction. decide that with me, then implement on both sides", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "i'd like to understand how the autoscaler decides to add instances during the spike", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "why does the nurturing job touch every pool record, and what does it actually change", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "is it expected that a job advert can be accepted by the board and then silently discarded", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment le point de restauration gère un redémarrage sur un nombre de rangs différent ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/checkpoints.md claims restarts are bit-for-bit reproducible, which they are not", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "partner changelog needs an entry for the job board key rotation and what it broke", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "doc comment on renderToBitmap claims it streams, which it very much does not", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "write the note to affected candidates whose interview email showed the wrong time", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "health endpoint reports the sync healthy while the job board has discarded everything for three weeks", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "apply endpoint awaits two emails before responding, which holds a connection for over a second", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "staging runs one app instance and prod runs forty, with the same per-instance connection limit", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "how should we handle a customer who wants their ATS data in their own region", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "what's the right way to validate a simulation change when the reference is a published number", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether the till should hold stock state locally or always ask the backend", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "three customers want single sign-on into the recruiter app with different providers", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "we need a plan for running the simulation on GPUs, which the next cluster procurement assumes", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "stores run four android versions and we've never dropped one", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to a candidate's data when a customer leaves us", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "an endpoint that returns an application's full stage history with who moved it and when", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "pipeline board needs a bulk action bar that states how many candidates it will affect", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "simulation's progress output should be parseable rather than a wall of formatted text", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "whatever we can ship before the audit", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "rest of the till work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "email templates format dates with the server's locale and timezone rather than the recipient's, which is the same class of bug as the interview emails but affects every template we send. centralise the formatting with the recipient's zone as the input, and tell me which templates change appearance for which recipients before we ship it", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "till keeps two receipt models, one for the printer and one for the customer copy, synchronised by hand and already divergent on discount lines. merge them, and confirm from the last month's receipts whether any customer copy has actually shown a different total from the printed one it doesn't have to be elegant, it has to be defensible in a review.", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "internal page on the apply pipeline stops at \"the form posts to the API\", and everything after — the two awaited emails, the recruiter fan-out, the connection cost of each — is why nobody understands the morning spike. write the page properly, following one application from the form to the recruiter's inbox", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "job scripts we hand researchers request eight tasks of sixteen threads on 128-core nodes and then take the whole node exclusively, which is most of our reported 12% efficiency. fix the templates, and add a comment explaining the arithmetic so the next person doesn't quietly restore the old numbers there's no rush on this week specifically, but it keeps costing us time.", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "nobody has been able to tell me what happens to an offer when the HRIS push fails all three attempts — whether the ticket that gets created is actually worked, whether the offer shows any sign of being unsynced, and how the customer finds out. trace it end to end and tell me how many offers are currently in that state", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "recruiter reports module builds its queries with raw SQL and a tenant id interpolated by hand, and one of them takes the tenant from a query parameter rather than the session. read the module and tell me whether a recruiter can reach another tenant's data today, with the specific request that would do it if so", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "simulation reads input files three different ways and two of them treat comment characters differently, which means the same input file can produce two different runs depending on which path parses it. unify the reader, and check whether any of our stored regression inputs relies on the lenient behaviour the last person who touched this left, so there's nobody to ask.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "`Application.stage` is a pipeline stage in the API, a lifecycle state in the database and something in between in the reports, which is why archived means two different things. give the concepts separate names and migrate the data, keeping the API's field names unchanged for the customers embedding our widget i'd like enough detail that i can hand it to someone else to finish.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "scan idempotency needs a device-persistent identifier rather than a counter that resets when a handheld is docked, which means the handhelds need a stable id we can trust across firmware updates and battery swaps. design that with the constraint that four hundred devices are already in stores, then implement the backend side we've been burned by guessing at this before, so evidence over instinct please.", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "a manager screen showing today's offline transactions and their outcomes is now contractual, and it has to work on the till itself because that's the only device a store manager has. build it against the offline transaction table, including the declined ones from previous days that nobody has acknowledged 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.6, "slice": "core", "lang": "en"}
{"prompt": "stock levels", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "one receipt model, not two", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "ATS has three ways of resolving the current tenant — a session field, a header the reports module trusts, and a query parameter one legacy endpoint still accepts — and new code copies whichever it finds first. reduce it to one resolution path with the others explicitly rejected, and keep every current client working while we migrate them", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "till's stock cache, the backend's stock table and the handheld's local queue are three views of the same number that reconcile only overnight, which is why staff trust none of them. bring them onto one model with explicit staleness, keeping the till usable while offline, and tell me what changes about the numbers staff see during the day", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "interview scheduling logic exists in the API and again in the calendar sync worker, and they disagree about what happens when an interviewer declines after the candidate has confirmed. consolidate them, with the API's behaviour as the reference, and list every scheduled interview whose state would differ under the unified logic", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "before i approve the offline limits work, i'd like to understand what the till currently does when a card is declined for an offline voucher taken three days ago — whether the customer is contacted, whether the store absorbs it, and whether anything in the product records that it happened at all", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "HRIS pusher should reconcile nightly rather than leaving an offer accepted on our side and absent from the customer's system with nothing to indicate the divergence. build the reconciliation against their employee list endpoint, handle their nightly maintenance window, and make a persistent divergence visible to the recruiter rather than only to us", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt":"Compare the old and new NorthstarCopperBridgeFlow adapters for ordering, error mapping, and shutdown guarantees; report semantic differences without proposing edits. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Please resist widening this one: NorthstarHarborIndexService works, but staging still carries a setting that production corrected last month. Change the staging timeout from 15 seconds to 30, adjust the adjacent assertion that encodes that value, and avoid unrelated formatting, renames, dependency bumps, or cleanup.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarHarborIndexService\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Spell NorthstarBirchMigratorStore's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Request: Incident timeline — INC-54138\n\n08:02 deploy NorthstarIrisBatchFlow 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 NorthstarIrisBatchFlow 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":"Match NorthstarMicaProfileService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"UI ticket DES-54110: finish the compact NorthstarOpalRouterFlow filter experience\n\nRoute: /catalog/search\nSource: projects/northstar/internal/auth/refresh.go\nFramework: Spring Boot\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible NorthstarOpalRouterFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Goal: # projects/northstar/workers/thumbnail/consumer.ex\n[worker.northstaramberfilterflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.northstaramberfilterflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.northstaramberfilterflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.NorthstarAmberFilterFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-54139\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/northstar/workers/thumbnail/consumer.ex. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"diff --git a/projects/northstar/src/sync/reconcile.ts b/projects/northstar/src/sync/reconcile.ts\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/src/sync/reconcile.ts\n+++ b/projects/northstar/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\nRead the artifact above as a skeptical reviewer. Is NorthstarCraneWorkspaceCoordinator's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"UI ticket DES-54148: finish the compact NorthstarFernSnapshotFlow filter experience\n\nRoute: /catalog/search\nSource: projects/northstar/db/migrations/20260730_events.sql\nFramework: Kotlin coroutines\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nBring NorthstarFernSnapshotFlow's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"PM is preparing the NorthstarMoonlitSDKStore rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarMoonlitSDKStore\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Give NorthstarKiteSchedulerService a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The NorthstarFrostPanelStore 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":"A previously stable test around NorthstarMosaicGridService 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":"Symptom: Incident timeline — INC-54126\n\n08:02 deploy NorthstarBasilRunnerFlow 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 NorthstarBasilRunnerFlow 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":"Milestones for replacing NorthstarMapleQueueStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"NorthstarMarbleTokenService needs an idempotent replay endpoint backed by Cloudflare Workers; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"NorthstarCoralUploadStore 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.6,"slice":"core","lang":"en"}
{"prompt":"NorthstarMoonlitSDKCoordinator: diagnose, then document","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarQuartzPlayerCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"# CI job 54132: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: Kafka\n\n[setup] restoring cache key deps-a2f91c ... hit\n[setup] starting postgres:17 ... healthy after 4.2s\n[setup] starting redis:8 ... healthy after 0.8s\n[test] shard 3/8 selected 412 tests\n[test] NorthstarKiteSchedulerFlowIntegration.replays_after_timeout ... ok\n[test] NorthstarKiteSchedulerFlowIntegration.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 NorthstarKiteSchedulerFlow 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":"Headsup: // projects/northstar/Sources/CLI/Commands/Doctor.swift\nfinal class NorthstarCinderAuthFlowCoordinator {\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 NorthstarCinderAuthFlow 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":"Bring NorthstarAtlasSearchStore'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":"In projects/northstar/packages/api/openapi.yaml hat NorthstarNovaPickerService ein sporadisches Problem im GraphQL-Ablauf. Verfasse eine Consumer-Doku mit Vertrag, Fehlern, Retry und einem kopierbaren Beispiel; ändere keinen Handler.\n\nRandbedingungen:\n- GraphQL weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf NorthstarNovaPickerService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um NorthstarNovaPickerService mit GraphQL kompatibel.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"NorthstarTideWorkerFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/northstar/ui/settings/PrivacyPane.tsx and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Match NorthstarEchoRegistryService's dark theme","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Two deliverables are holding up NorthstarOspreyJobCoordinator. First, assess ownership and failure handling in projects/northstar/Sources/CLI/Commands/Doctor.swift. In the same workstream, capture the contract and rollback note for consumers. The relevant starting point is projects/northstar/Sources/CLI/Commands/Doctor.swift, which follows Kafka conventions and currently suffers from lost focus when the drawer animation finishes. Make rollback possible without deleting user data.\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":"FYI: # projects/northstar/src/sync/reconcile.ts\n[worker.northstarnimbusformflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.northstarnimbusformflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.northstarnimbusformflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.NorthstarNimbusFormFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-54118\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/northstar/src/sync/reconcile.ts. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"NorthstarLumenChartCoordinator: diagnose, then document","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"The NorthstarCedarPolicyFlow 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":"NorthstarFlintTimelineCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Before we approve NorthstarOrbitSyncStore, assess whether a misleading timeout name used in five packages is an actual correctness risk or merely confusing structure. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"We expect NorthstarDeltaCanvasStore to outgrow its current Spring Boot arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- make rollback possible without deleting user data\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to NorthstarDeltaCanvasStore and its direct tests\n\nSeveral teams work in this developer tools, Java, WebGL 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":"Does NorthstarEchoRegistryStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-54116\n\n08:02 deploy NorthstarGarnetModalFlow 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 NorthstarGarnetModalFlow 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":"I inherited NorthstarCopperBridgeService and need a careful read of projects/northstar/web/components/FilterDrawer.vue before I can sign off on the next release. 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- make rollback possible without deleting user data\n- stay compatible with the existing Spring Boot deployment\n- keep the work scoped to NorthstarCopperBridgeService and its direct tests\n\nSeveral teams work in this developer tools, Java, WebGL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/northstar/pkg/cache/lease.rs b/projects/northstar/pkg/cache/lease.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/pkg/cache/lease.rs\n+++ b/projects/northstar/pkg/cache/lease.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\nRead the artifact above as a skeptical reviewer. Is NorthstarFrostPanelFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Give NorthstarBirchMigratorService a README example","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Pin NorthstarWillowCodecStore's Kotlin dependency","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Meanwhile: diff --git a/projects/northstar/config/staging.toml b/projects/northstar/config/staging.toml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/config/staging.toml\n+++ b/projects/northstar/config/staging.toml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate NorthstarBeaconStoreFlow'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":"Ownership of NorthstarPrismCacheStore is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Kotlin coroutines operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"NorthstarOrbitSyncService occasionally exhibits two validators with subtly different error strings, but only after a reconnect. Follow the data and cancellation paths in projects/northstar/infra/modules/edge/main.tf and identify the cause before changing anything.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"En projects/northstar/config/staging.toml, NorthstarNovaPickerStore tiene un problema intermitente en el flujo de GraphQL. Propón fases, compatibilidad, métricas, rollback y ownership; detente antes de tocar código.\n\nRestricciones:\n- seguir con GraphQL\n- conservar compatibilidad y cancelación\n- limitar el cambio a NorthstarNovaPickerStore Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con GraphQL alrededor de NorthstarNovaPickerStore.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"es"}
{"prompt":"Locally: The NorthstarQuartzPlayerStore surface in projects/northstar/services/ledger/replay.go is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"NorthstarAtlasSearchService'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":"Production: The API work is done; what remains for NorthstarPineMetricsService is the visible interaction layer across loading, offline, empty, and success cases. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarPineMetricsService\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Staging: The NorthstarSlateEditorService empty state in projects/northstar/ml/pipeline/features.py needs a quiet illustration, a retry button, and copy that distinguishes no results from an offline response.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-54114\n\n08:02 deploy NorthstarSableParserFlow 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 NorthstarSableParserFlow 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":"Is NorthstarVelaDrawerStore safe under cancellation?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"CI: The NorthstarAmberFilterStore surface in projects/northstar/ui/settings/PrivacyPane.tsx 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":"Investigate the NorthstarBasilRunnerService hang","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Atlas: Incident timeline — INC-54130\n\n08:02 deploy NorthstarDriftConsoleFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current NorthstarDriftConsoleFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current NorthstarOpalRouterService design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarOpalRouterService\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"What does NorthstarFlintTimelineStore own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-54121: retire the legacy replay path for NorthstarMicaProfileFlow\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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Capture the NorthstarMicaProfileFlow 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":"NorthstarNimbusFormCoordinator: correct, then assess","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Beacon: The minimum supported Cloudflare Workers version in projects/northstar/engine/render/atlas.cpp is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"NorthstarAmberFilterCoordinator: make this less weird","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/northstar/packages/api/openapi.yaml b/projects/northstar/packages/api/openapi.yaml\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/packages/api/openapi.yaml\n+++ b/projects/northstar/packages/api/openapi.yaml\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure NorthstarMapleQueueFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"NorthstarSlateEditorCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Test Suite 'NorthstarPineMetricsCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[NorthstarPineMetricsCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/northstar/packages/api/openapi.yaml:144: error: -[NorthstarPineMetricsCoordinatorTests 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 '-[NorthstarPineMetricsCoordinatorTests 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\nBring NorthstarPineMetricsCoordinator's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"What sequence would let NorthstarAmberFilterService adopt Cloudflare Workers with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Set NorthstarLumenChartStore's port to 8081","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"For NorthstarWillowCodecCoordinator, separate NorthstarWillowCodecCoordinator's policy from transport without behavior changes; once that is complete, capture the contract and rollback note for consumers. Work from projects/northstar/src/sync/reconcile.ts, stay with Kotlin coroutines, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Cinder: Incident timeline — INC-54152\n\n08:02 deploy NorthstarCedarPolicyCoordinator 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 NorthstarCedarPolicyCoordinator 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":"Delta: diff --git a/projects/northstar/infra/modules/edge/main.tf b/projects/northstar/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/infra/modules/edge/main.tf\n+++ b/projects/northstar/infra/modules/edge/main.tf\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRead the artifact above as a skeptical reviewer. Is NorthstarOrbitSyncFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Documente o contrato de NorthstarEmberRelayService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"pt"}
{"prompt":"NorthstarMapleQueueService leaks tasks on shutdown","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"The name pendingAck means two different things across NorthstarHarborIndexStore's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Design handed over a final pass for NorthstarTideWorkerStore, and the basic data flow in projects/northstar/workers/thumbnail/consumer.ex already works. 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- make rollback possible without deleting user data\n- stay compatible with the existing Cloudflare Workers deployment\n- keep the work scoped to NorthstarTideWorkerStore and its direct tests\n\nSeveral teams work in this developer tools, Java, WebGL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Move NorthstarVelaDrawerService behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"NorthstarCinderAuthCoordinator: diagnose, then correct","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"NorthstarSlateEditorStore'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":"Ember: What is the safest way to split projects/northstar/apps/console/routes/usage.svelte into independently owned modules while NorthstarRainfallDBStore's public behavior remains frozen for the next release?","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"en"}
{"prompt":"NorthstarSableParserCoordinator is blocking the next release because an accessibility label that reads the internal enum. I need two concrete outcomes from a single pass: change NorthstarSableParserCoordinator's known staging timeout from 15 to 30 seconds, and capture the contract and rollback note for consumers. Use the existing Cloudflare Workers conventions in projects/northstar/engine/render/atlas.cpp; make rollback possible without deleting user data. 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":"Security flagged NorthstarGarnetModalStore for a read-only pass because its GraphQL boundary mixes tenant data, retries, and cancellation in subtle ways. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current GraphQL operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.\n\nNothing is reported broken, so judge and explain current behavior without inventing a failure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-54129: retire the legacy replay path for NorthstarEchoRegistryFlow\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Assess NorthstarEchoRegistryFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"planning","secondary":"review","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"Corrige le timeout de NorthstarEmberRelayStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"fr"}
{"prompt":"// projects/northstar/services/ledger/replay.go\nfinal class NorthstarDeltaCanvasFlowCoordinator {\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 NorthstarDeltaCanvasFlow; 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":"NorthstarEmberRelayCoordinator needs a paired pass: assess ownership and failure handling in projects/northstar/cmd/exporter/main.py, plus capture the contract and rollback note for consumers. Use projects/northstar/cmd/exporter/main.py as the source of truth, preserve the Kafka contract, and avoid unrelated cleanup.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"We expect NorthstarCraneWorkspaceService to outgrow its current Kotlin coroutines arrangement next quarter, but changing everything at once would be risky. Lay out milestones for dual operation, validation, client adoption, cutover, and removal, with a named owner and measurable exit condition for every phase.\n\nConstraints:\n- make rollback possible without deleting user data\n- stay compatible with the existing Kotlin coroutines deployment\n- keep the work scoped to NorthstarCraneWorkspaceService and its direct tests\n\nSeveral teams work in this developer tools, Java, WebGL 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":"projects/northstar/services/ledger/replay.go 里的 NorthstarSummitProxyService 最近在 Spring Boot 流程中出现间歇性问题。 请实现幂等 endpoint，包含持久 cursor、tenant 鉴权、spans 和 retry 测试。\n\n约束：\n- 继续使用 Spring Boot\n- 保持兼容性和取消语义\n- 改动只限于 NorthstarSummitProxyService","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"NorthstarVelaDrawerCoordinator needs a paired pass: separate NorthstarVelaDrawerCoordinator's policy from transport without behavior changes, plus give the existing implementation a read-only safety pass. Use projects/northstar/app/src/main/SyncWorker.kt as the source of truth, preserve the Kotlin coroutines contract, and avoid unrelated cleanup.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Document NorthstarSableParserService's cancellation rules","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Frost: Ticket OPS-54111: retire the legacy replay path for NorthstarNovaPickerFlow\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 NorthstarNovaPickerFlow 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":"Garnet: projects/northstar/app/src/main/SyncWorker.kt の NorthstarWrenExportService で、Kotlin coroutines の flow に断続的な問題が起きています。 責務を分離して重複をなくし、API、wire value、順序、観測可能な動作は変えないでください。\n\n制約:\n- Kotlin coroutines を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は NorthstarWrenExportService のみ","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"ja"}
{"prompt":"Persist NorthstarQuartzPlayerService delivery attempts in projects/northstar/web/components/FilterDrawer.vue, claim them safely across workers, and make duplicate webhook receipts return the original accepted result.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/northstar/app/src/main/SyncWorker.kt b/projects/northstar/app/src/main/SyncWorker.kt\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/app/src/main/SyncWorker.kt\n+++ b/projects/northstar/app/src/main/SyncWorker.kt\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure NorthstarWrenExportFlow so duplicated normalization and shutdown ownership have one home. Preserve public behavior, wire values, logging fields, and ordering; extend characterization coverage first.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Flip NorthstarMicaProfileStore's staging toggle","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for NorthstarPrismCacheCoordinator:\n- primary outcome: produce a consumer guide for NorthstarPrismCacheCoordinator\n- companion outcome: give the existing implementation a read-only safety pass\n- repository entry point: projects/northstar/app/src/main/SyncWorker.kt\n- platform constraint: Kotlin coroutines\n- known complication: timestamps rendered one day ahead near UTC midnight\n\nBoth results are required, but they should remain independently reviewable. Make rollback possible without deleting user data; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Move NorthstarMoonlitSDKService behind one protocol","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Harbor: Ticket OPS-54159: retire the legacy replay path for NorthstarTideWorkerCoordinator\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 NorthstarTideWorkerCoordinator, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"The name pendingAck means two different things across NorthstarMarbleTokenStore's packages; rename the state and its helpers consistently while keeping wire keys untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Iris: projects/northstar/lib/codec/frame.cc now contains NorthstarAcornWidgetStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: NorthstarCedarPolicyService has one known configuration mistake in projects/northstar/Sources/CLI/Commands/Doctor.swift, not an open-ended failure investigation. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- make rollback possible without deleting user data\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to NorthstarCedarPolicyService and its direct tests\n\nSeveral teams work in this developer tools, Java, WebGL monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Juniper: diff --git a/projects/northstar/db/migrations/20260730_events.sql b/projects/northstar/db/migrations/20260730_events.sql\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/db/migrations/20260730_events.sql\n+++ b/projects/northstar/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\nRead the artifact above as a skeptical reviewer. Is NorthstarWillowCodecFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"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_54145'\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_54145'::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\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Find the source of this NorthstarQuartzPlayerFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Kestrel: The public surface of NorthstarCloudReconcilerService is frozen, but its internal ownership in projects/northstar/ml/pipeline/features.py is difficult to test and even harder to change safely. 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- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarCloudReconcilerService\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Animate the NorthstarCinderAuthService drawer","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"NorthstarMarbleTokenCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"NorthstarTideWorkerService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Cloudflare Workers operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Lumen: Ticket OPS-54157: retire the legacy replay path for NorthstarCloudReconcilerCoordinator\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 NorthstarCloudReconcilerCoordinator 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":"Maple: What sequence would let NorthstarCloudReconcilerStore adopt Kafka with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Nimbus: # projects/northstar/apps/console/routes/usage.svelte\n[worker.northstarveladrawerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.northstarveladrawerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.northstarveladrawerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.NorthstarVelaDrawerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-54133\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/northstar/apps/console/routes/usage.svelte. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"UI ticket DES-54154: finish the compact NorthstarHarborIndexCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/northstar/lib/codec/frame.cc\nFramework: Cloudflare Workers\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nBring NorthstarHarborIndexCoordinator's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"NorthstarIrisBatchStore's staging timeout is already known to be wrong: change the single projects/northstar/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":"Incident timeline — INC-54134\n\n08:02 deploy NorthstarMarbleTokenFlow 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 NorthstarMarbleTokenFlow 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":"Ticket OPS-54119: retire the legacy replay path for NorthstarRavenSessionFlow\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 NorthstarRavenSessionFlow 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":"NorthstarIrisBatchCoordinator: smooth out this interaction","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"NorthstarSummitProxyCoordinator: ship a sensible version","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Opal: projects/northstar/Sources/CLI/Commands/Doctor.swift has grown through several launches, and NorthstarOspreyJobStore now mixes policy, transport, persistence, and metrics in one place. Introduce one ownership boundary for storage and scheduling, collapse pass-through wrappers, and characterize ordering and cancellation before moving code.\n\nConstraints:\n- make rollback possible without deleting user data\n- stay compatible with the existing Kafka deployment\n- keep the work scoped to NorthstarOspreyJobStore and its direct tests\n\nSeveral teams work in this developer tools, Java, WebGL 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":"Prism: projects/northstar/apps/console/routes/usage.svelte 里的 NorthstarWrenExportStore 最近在 Kotlin coroutines 流程中出现间歇性问题。 请完成 responsive layout、空状态、retry、键盘焦点、dark mode 和 reduced motion。\n\n约束：\n- 继续使用 Kotlin coroutines\n- 保持兼容性和取消语义\n- 改动只限于 NorthstarWrenExportStore","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"zh"}
{"prompt":"Clarify NorthstarSpruceDaemonStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Quartz: The NorthstarBeaconStoreService surface in projects/northstar/config/staging.toml 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":"diff --git a/projects/northstar/cmd/exporter/main.py b/projects/northstar/cmd/exporter/main.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/cmd/exporter/main.py\n+++ b/projects/northstar/cmd/exporter/main.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Deliver the NorthstarAtlasSearchFlow 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":"Raven: projects/northstar/config/staging.toml の NorthstarPineMetricsFlow で、GraphQL の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- GraphQL を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は NorthstarPineMetricsFlow のみ","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"ja"}
{"prompt":"Sable: The first NorthstarPineMetricsStore request after credential refresh gets 401, while an immediate retry succeeds. Follow token publication and request capture timing before recommending a fix.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"For NorthstarSpruceDaemonCoordinator, assess ownership and failure handling in projects/northstar/services/ledger/replay.go; once that is complete, capture the contract and rollback note for consumers. Work from projects/northstar/services/ledger/replay.go, stay with Spring Boot, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Draft NorthstarDeltaCanvasService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Two asks around NorthstarEchoRegistryCoordinator: (1) finish NorthstarEchoRegistryCoordinator's responsive empty and retry states; (2) capture the contract and rollback note for consumers. Make rollback possible without deleting user data, and leave a clear boundary between the resulting artifacts or edits.","purpose":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Test Suite 'NorthstarLedgerGateFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[NorthstarLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/northstar/ui/settings/PrivacyPane.tsx:144: error: -[NorthstarLedgerGateFlowTests 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 '-[NorthstarLedgerGateFlowTests 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\nFinish the visible NorthstarLedgerGateFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"The minimum supported Kotlin coroutines version in projects/northstar/src/sync/reconcile.ts 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":"Is there a cleaner way to separate NorthstarCloudReconcilerFlow's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"NorthstarAtlasSearchCoordinator: make the api less awkward","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Introduce a durable deduplication key for NorthstarCraneWorkspaceFlow events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Tide: The API work is done; what remains for NorthstarCraneWorkspaceStore is the visible interaction layer across loading, offline, empty, and success cases. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarCraneWorkspaceStore\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Split NorthstarFlintTimelineService without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Before we approve NorthstarFernSnapshotService, assess whether an empty state that flashes before cached data arrives is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Fresh release brief for NorthstarOpalRouterCoordinator:\n- primary outcome: lay out a staged migration for NorthstarOpalRouterCoordinator\n- companion outcome: then implement the bounded durable-cursor handler\n- repository entry point: projects/northstar/infra/modules/edge/main.tf\n- platform constraint: Spring Boot\n- known complication: an empty state that flashes before cached data arrives\n\nBoth results are required, but they should remain independently reviewable. Make rollback possible without deleting user data; 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":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarRainfallDBFlow returns one extra item only when the page boundary lands on a deleted record. Reconstruct the cursor transitions in projects/northstar/app/src/main/SyncWorker.kt and find where the invariant breaks.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"projects/northstar/infra/modules/edge/main.tf now contains NorthstarJuniperCLIFlow's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"NorthstarRavenSessionService est-il sûr ?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"fr"}
{"prompt":"Ticket OPS-54153: retire the legacy replay path for NorthstarRainfallDBCoordinator\n\nBackground\nThe mobile clients now send monotonic cursors, but the worker still supports the pre-2024 offset token. That compatibility branch performs an extra database lookup on every page and owns a separate retry counter. Support confirmed that the oldest active client is version 8.14, which uses cursors.\n\nAcceptance notes\n- existing cursor tokens must remain valid during a two-release overlap\n- operators need one metric showing legacy traffic by client version\n- a rollback must not require restoring deleted columns\n- tenant isolation remains enforced in the storage query\n- SDK examples should show how to persist the continuation token\n- the public route and current 429 envelope cannot change\n\nOpen questions\nDo we delete the offset decoder immediately or quarantine it behind a flag? Who owns the mobile version gate? Can the database index be removed in the same deploy? Security wants evidence that forged cursors cannot select another tenant.\n\nSlack excerpt\nMina 09:42: “I can provide client adoption numbers, but not a guarantee about sideloaded builds.”\nRavi 09:47: “Please make the rollback trigger explicit; queue lag alone is too noisy.”\n\n上のコンテキストを基に依頼された作業を行い、API、互換性、rollback を維持し、根拠と判断を明確にしてください。 Assess NorthstarRainfallDBCoordinator 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":"Responsive layout for NorthstarKiteSchedulerStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Find NorthstarDriftConsoleService's duplicate retry source","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Umbra: Ticket OPS-54127: retire the legacy replay path for NorthstarEmberRelayFlow\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 NorthstarEmberRelayFlow 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":"NorthstarFrostPanelCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"PM is preparing the NorthstarPrismCacheService rollout and needs prose that works for both application developers and the operators who will carry the pager. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarPrismCacheService\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Split projects/northstar/workers/thumbnail/consumer.ex by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"projects/northstar/pkg/cache/lease.rs now contains NorthstarFrostPanelService's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-54136\n\n08:02 deploy NorthstarMosaicGridFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the NorthstarMosaicGridFlow 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":"Introduce a durable deduplication key for NorthstarCoralUploadService events and enforce it in both the database migration and the ingestion path.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Sequence NorthstarNimbusFormStore's rollout","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Move NorthstarBeaconStoreStore'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":"Vela: Ticket OPS-54123: retire the legacy replay path for NorthstarLumenChartFlow\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 NorthstarLumenChartFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Test Suite 'NorthstarPrismCacheFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[NorthstarPrismCacheFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/northstar/apps/console/routes/usage.svelte:144: error: -[NorthstarPrismCacheFlowTests 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 '-[NorthstarPrismCacheFlowTests 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\nCon este contexto, resuelve la petición indicada manteniendo API, compatibilidad y rollback; deja claras las decisiones y la evidencia. Finish the visible NorthstarPrismCacheFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"debugging","secondary":"frontendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Walk through NorthstarBasilRunnerStore's segment.rs","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/northstar/web/components/FilterDrawer.vue b/projects/northstar/web/components/FilterDrawer.vue\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/web/components/FilterDrawer.vue\n+++ b/projects/northstar/web/components/FilterDrawer.vue\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nRestructure NorthstarSpruceDaemonFlow 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":"NorthstarAcornWidgetCoordinator: handle the lingering thing","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"For NorthstarMapleQueueCoordinator, produce a consumer guide for NorthstarMapleQueueCoordinator; once that is complete, give the existing implementation a read-only safety pass. Work from projects/northstar/config/staging.toml, stay with GraphQL, and make rollback possible without deleting user data. Keep the two outcomes separately reviewable.","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarGarnetModalCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Ownership of NorthstarJuniperCLIService is moving between teams while old clients remain active, so we need an executable migration sequence before touching files. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Spring Boot operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"On compact widths, NorthstarCedarPolicyStore's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Two asks around NorthstarBasilRunnerCoordinator: (1) separate NorthstarBasilRunnerCoordinator's policy from transport without behavior changes; (2) correct the known stale timeout beside it. Make rollback possible without deleting user data, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarFernSnapshotCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Design the NorthstarGarnetModalService rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Willow: Two deliverables are holding up NorthstarDeltaCanvasCoordinator. First, produce a consumer guide for NorthstarDeltaCanvasCoordinator. In the same workstream, correct the known stale timeout beside it. The relevant starting point is projects/northstar/web/components/FilterDrawer.vue, which follows Spring Boot conventions and currently suffers from lease renewal code copied across three workers. Make rollback possible without deleting user data.\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":"writing","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarJuniperCLIStore 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":"Give NorthstarWillowCodecService a loading skeleton","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"NorthstarMosaicGridCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"NorthstarOrbitSyncCoordinator: sort out the rough edge","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"NorthstarWrenExportCoordinator: give it a nicer flow","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"The minimum supported GraphQL version in projects/northstar/pkg/cache/lease.rs 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":"Read projects/northstar/pkg/cache/lease.rs and tell me whether NorthstarAsterWebhookFlow can acknowledge work before its durable write completes; this is a read-only safety pass. Nothing is reported broken, so keep this to an explanation of current behavior.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"NorthstarBeaconStoreCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Xylem: # projects/northstar/services/ledger/replay.go\n[worker.northstarsummitproxyflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.northstarsummitproxyflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.northstarsummitproxyflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.NorthstarSummitProxyFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-54135\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 NorthstarSummitProxyFlow'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":"Spell NorthstarNimbusFormService's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"NorthstarLedgerGateCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Yarrow: # projects/northstar/services/ledger/replay.go\n[worker.northstarcopperbridgecoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.northstarcopperbridgecoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.northstarcopperbridgecoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.NorthstarCopperBridgeCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-54155\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/northstar/services/ledger/replay.go and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Zephyr: The behavior of NorthstarOpalRouterStore is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/northstar/infra/modules/edge/main.tf. 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- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Spring Boot operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"En projects/northstar/app/src/main/SyncWorker.kt, NorthstarRainfallDBService tiene un problema intermitente en el flujo de Kotlin coroutines. Separa responsabilidades y elimina duplicación, conservando API, wire values, orden y comportamiento observable.\n\nRestricciones:\n- seguir con Kotlin coroutines\n- conservar compatibilidad y cancelación\n- limitar el cambio a NorthstarRainfallDBService","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"es"}
{"prompt":"Checkout: // projects/northstar/engine/render/atlas.cpp\nfinal class NorthstarAcornWidgetFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate NorthstarAcornWidgetFlow'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":"Nobody is asking for code changes yet; we first need to understand whether the current NorthstarSableParserStore design actually guarantees what its callers assume. Trace ownership, ordering, error propagation, and cancellation; call out concrete risks with file references, but do not edit the implementation or turn the answer into a replacement design.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside NorthstarSableParserStore\n- make rollback possible without deleting user data\n\nThis repository spans developer tools, Java, WebGL; use its existing conventions rather than importing a new abstraction.\n\nNothing is reported broken, so judge and explain current behavior without inventing a failure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Remove NorthstarDriftConsoleStore's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"NorthstarMicaProfileCoordinator: ship, then assess","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Add a bounded NorthstarHarborIndexFlow export stream that resumes from checkpoints, respects cancellation, and exposes queue lag plus terminal failure counters.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two engineers disagree about whether NorthstarCopperBridgeStore's cache is authoritative. Walk the reads and writes in projects/northstar/services/ledger/replay.go and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Exporter: // projects/northstar/Sources/App/SessionStore.swift\nfinal class NorthstarOspreyJobFlowCoordinator {\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 NorthstarOspreyJobFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Scheduler: Two asks around NorthstarKiteSchedulerCoordinator: (1) assess ownership and failure handling in projects/northstar/Sources/CLI/Commands/Doctor.swift; (2) capture the contract and rollback note for consumers. Make rollback possible without deleting user data, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Dashboard: # projects/northstar/cmd/exporter/main.py\n[worker.northstarmoonlitsdkflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.northstarmoonlitsdkflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.northstarmoonlitsdkflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.NorthstarMoonlitSDKFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-54117\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 NorthstarMoonlitSDKFlow'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":"Where did NorthstarCinderAuthStore's cursor drift?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Release engineering needs a NorthstarAsterWebhookStore changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/northstar/ml/pipeline/features.py b/projects/northstar/ml/pipeline/features.py\nindex 62d71aa..90f3c1e 100644\n--- a/projects/northstar/ml/pipeline/features.py\n+++ b/projects/northstar/ml/pipeline/features.py\n@@ -41,18 +41,27 @@ export async function reconcile(input: Batch) {\n- const rows = input.items.map(normalize);\n- await store.write(rows);\n- await metrics.count(\"reconciled\", rows.length);\n+ const scope = tracer.startActiveSpan(\"reconcile\");\n+ try {\n+ const rows = input.items.map(normalize);\n+ await Promise.all([\n+ store.write(rows),\n+ metrics.count(\"reconciled\", rows.length),\n+ ]);\n+ return { cursor: input.next, count: rows.length };\n+ } finally {\n+ scope.end();\n+ }\n }\n\n@@ -88,7 +97,11 @@ function normalize(item: WireItem): Row {\n- return { id: item.id, value: item.payload ?? \"\" };\n+ return {\n+ id: item.id.trim(),\n+ value: item.payload?.normalize(\"NFC\") ?? \"\",\n+ receivedAt: clock.now(),\n+ };\n }\n\nPR note: staging p95 drops by 18 ms. Tests assert row counts but not whether metrics happen before the durable write.\n\nConsolidate NorthstarSlateEditorFlow'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":"NorthstarRavenSessionCoordinator: ship, then correct","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_54124'\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_54124'::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\nFind the source of this NorthstarBirchMigratorFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.9,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarAsterWebhookService is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Implement the remaining visual states from the design tokens, including compact navigation, offline recovery, destructive confirmation, and animation fallbacks.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current GraphQL operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"NorthstarCoralUploadCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"NorthstarDriftConsoleCoordinator needs a paired pass: produce a consumer guide for NorthstarDriftConsoleCoordinator, plus correct the known stale timeout beside it. Use projects/northstar/infra/modules/edge/main.tf as the source of truth, preserve the Spring Boot contract, and avoid unrelated cleanup.","purpose":"writing","secondary":"quickFix","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"NorthstarNovaPickerCoordinator is blocking the next release because a flaky snapshot caused by locale-dependent sorting. I need two concrete outcomes from a single pass: separate NorthstarNovaPickerCoordinator's policy from transport without behavior changes, and correct the known stale timeout beside it. Use the existing GraphQL conventions in projects/northstar/config/staging.toml; make rollback possible without deleting user data. 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":"refactor","secondary":"quickFix","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Support wants the behavior in projects/northstar/ui/settings/PrivacyPane.tsx recast as a troubleshooting page: symptoms first, then checks, recovery, and an escalation boundary.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"Before touching projects/northstar/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.8,"slice":"core","lang":"en"}
{"prompt":"Map NorthstarLumenChartService's ownership split","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"The behavior of NorthstarOspreyJobService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/northstar/Sources/App/SessionStore.swift. 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- touch generated artifacts only through their checked-in generator\n- make rollback possible without deleting user data\n- retain the current Kafka operational envelope\n\nThe relevant code crosses developer tools, Java, WebGL. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Em projects/northstar/web/components/FilterDrawer.vue, o NorthstarSummitProxyStore tem um problema intermitente no fluxo de Spring Boot. Leia o fluxo atual e avalie ownership, cancelamento e ordem; preciso apenas da análise.\n\nRestrições:\n- continuar com Spring Boot\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao NorthstarSummitProxyStore","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"Incident timeline — INC-54142\n\n08:02 deploy NorthstarCoralUploadFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current NorthstarCoralUploadFlow 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":"$ pnpm test --filter NorthstarFlintTimelineFlow\n RUN v3.2.4 /workspace/apps/console\n × NorthstarFlintTimelineFlow > 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=54120 phase=resume storedCursor=seg-0183\n session=54120 phase=fetch requestCursor=seg-0183 pageSize=200\n session=54120 phase=commit receivedCursor=seg-0184 itemCount=0\n session=54120 phase=ack durable=false\n\nThe assertion passes when this file runs alone and fails about one time in twelve in the full shard. Fake time is reset in afterEach, Redis is flushed, and no production incident has been tied to it. CI uses Node 24 on Linux; local repro attempts were on macOS.\n\nReconstruct the NorthstarFlintTimelineFlow 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":"Any races in NorthstarSpruceDaemonService?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"2026-07-30T08:14:11.409Z level=info service=northstarasterwebhookcoordinator pod=northstarasterwebhookcoordinator-7cf8 request_id=54156 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=northstarasterwebhookcoordinator request_id=54156 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=northstarasterwebhookcoordinator request_id=54156 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=northstarasterwebhookcoordinator request_id=54156 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=northstarasterwebhookcoordinator request_id=54156 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=northstarasterwebhookcoordinator request_id=54156 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=northstarasterwebhookcoordinator request_id=54156 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=northstarasterwebhookcoordinator request_id=54156 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 NorthstarAsterWebhookCoordinator 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":"NorthstarBirchMigratorCoordinator needs a paired pass: finish NorthstarBirchMigratorCoordinator's responsive empty and retry states, plus correct the known stale timeout beside it. Use projects/northstar/lib/codec/frame.cc as the source of truth, preserve the Cloudflare Workers contract, and avoid unrelated cleanup.","purpose":"frontendImpl","secondary":"quickFix","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Warum hängt NorthstarRavenSessionStore?","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"de"}
{"prompt":"Incident timeline — INC-54150\n\n08:02 deploy NorthstarJuniperCLICoordinator 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 NorthstarJuniperCLICoordinator, 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"}
data/round2-15.jsonl
+200 -200
View File
@@ -1,200 +1,200 @@
{"prompt": "the cache key logic is spread across the config parser, the request handler and a per-customer override table:\n\n// config/parse.rs — builds a CacheKeySpec from the customer's yaml\n// handler/key.rs — builds the actual key, ignoring two fields of the spec\n// overrides.rs — a per-customer hashmap applied after the key is built, in production only\n\nthe overrides table has 41 entries, four of which contradict the customer's own config, and nobody knows who added them or why", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "our cache key configuration, which one customer's Vary header just multiplied by every user agent on the internet:\n\ncache_key:\n include: [scheme, host, path, query]\n vary: from_origin # we honour whatever the origin sends\n ignore_query_params: [utm_source, utm_medium, fbclid]\n normalize_accept_encoding: true\n\nthere is no cap on the number of variants per key, no warning when a Vary header would explode the key space, and a customer can do this with a one-line change on their side at any time\n\nwhat the key space did over the incident:\n distinct cache keys for /assets/app.js, before: 3\n after: 41,882 and climbing\n cache fill rate: 1.2 GB/min\n evictions: 8,400/s (previously ~0)\n\nand the customer's diff, in full:\n - Vary: Accept-Encoding\n + Vary: Accept-Encoding, User-Agent", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "field app deletes a queued photo when an upload returns any 4xx, which is how a customer lost the photographic evidence behind a variation claim. beyond the immediate fix, i want a position on what our offline guarantees actually are — what we promise never to lose, what the user is shown, and how we prove it after the fact — because the enterprise contract signing in november asks for exactly that", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "a customer whose payments API was unresolvable for two hours wants to know how an automated key roll can take a zone off the internet. write the incident report for their architecture team — the overlap arithmetic, why nothing caught it, and what changes — without retreating into DNSSEC jargon they'll have to look up whatever you find, write it somewhere the next person will actually look.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "the data team's list, with the recommender incident fresh:\n\n- output validation on the nightly job: row counts, distribution checks, comparison against yesterday\n- stop overwriting the table, write to a new partition and swap\n- the (user_id, context_id) grouping needs a different shape entirely, it doesn't fit in memory\n- the licensing filter should be somewhere legal can read it rather than inline in a 900-line object\n- adaptive query execution is off because someone turned it off in 2023\n- run time has crept from 70 minutes to three hours and nobody owns that\n\nthree engineers, and the nightly job feeds the 06:00 home screen", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "one anycast POP answers queries with the wrong zone data for about ninety seconds after each deploy:\n\n2026-07-29T11:02:14Z pop=fra1 zone=example.com serial=2026072901 source=cache age=0\n2026-07-29T11:02:14Z pop=fra1 zone=example.com serial=2026072814 source=disk age=86400\n2026-07-29T11:02:15Z pop=fra1 answered A example.com -> 203.0.113.9 (old target)\n2026-07-29T11:03:44Z pop=fra1 zone=example.com serial=2026072901 source=xfr age=0\n2026-07-29T11:03:45Z pop=fra1 answered A example.com -> 198.51.100.4 (correct)\n\nthe process starts serving from the on-disk snapshot before the zone transfer completes, and the snapshot can be a day old", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "edge cache hit rate collapsed for one customer overnight with no config change on our side:\n\n before: hit 94.1%, origin rps 1,204\n after: hit 41.2%, origin rps 18,882\n\nsample request/response:\n GET /assets/app.js\n Cache-Control: public, max-age=31536000\n Vary: Accept-Encoding, User-Agent\n ETag: W/\"a11c3f2-8814\"\n\nthe customer added User-Agent to Vary in a deploy yesterday, which multiplies cache entries by every UA string we see", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "our edge configuration API, which customers automate against from a README and a support engineer's memory:\n\nPUT /v1/zones/{zone}/config\n body: cache rules, origin settings, header transforms, WAF toggles\n applies globally within about 90 seconds, but a POP that restarts during that window may serve the previous config for its startup period\n a config that fails validation on one POP is still applied on the others; there is no atomic rollout\n the response is 202 with a deployment id, and GET on it reports \"complete\" once the last POP acknowledges — which is not the same as the config being live\n rate limited to 10 changes per zone per hour, undocumented, and returns 429 with no retry-after\n\nwrite the reference documentation, including the honest description of what \"complete\" means", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "field app's offline behaviour is described in the sales deck as \"works fully offline\" and the reality is three queues with three failure modes and no visibility. write the honest documentation for site staff and their IT departments, covering what is queued, what happens when an upload is rejected, and what conflicts do to their data", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "a customer's architecture review asked five questions about POP health, config rollback, transfer authentication, key rollover approval and self-service recovery. answer each from the code and the runbooks, and mark clearly the ones where the honest answer is that a human notices rather than a mechanism catching it context if it helps: this has been open since before i joined the team.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "zone view should sort by staleness", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "nightly job again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "one definition of downloaded", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "edge configuration API is automated against by customers who discovered its behaviour by experiment, including the undocumented rate limit and the fact that \"deployment complete\" doesn't mean the config is live everywhere. write the reference documentation, with those two stated plainly rather than left to be discovered again i'm not attached to the current approach if there's an obviously better one.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "before this goes to production, is the sync conflict handling defensible?\n\nFuture<void> sync() async {\n final local = await db.dirtyTasks();\n for (final t in local) {\n final remote = await api.getTask(t.id);\n if (remote == null) { await api.createTask(t); continue; }\n if (t.updatedAt.isAfter(remote.updatedAt)) {\n await api.updateTask(t); // whole record\n } else {\n await db.replaceTask(remote); // discards local edits silently\n }\n }\n}\n\nupdatedAt comes from the device clock, tablets on site are routinely minutes out, and a task record includes a free-text notes field several people edit", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "three parts of the app decide what \"downloaded\" means and they disagree:\n\n// LibraryView.swift\nlet isDownloaded = FileManager.default.fileExists(atPath: track.localURL.path)\n\n// DownloadManager.swift\nfunc isDownloaded(_ t: Track) -> Bool { store.state(for: t.id) == .complete }\n\n// SyncService.swift\nlet downloaded = try db.query(\"SELECT 1 FROM downloads WHERE track_id = ? AND expires_at > ?\", t.id, now)\n\nthe file can exist while the download record says failed, the record can say complete after the file was evicted by the OS, and the expiry is only checked in one of the three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "cache key logic in one place", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "what makes a zone \"current\"?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "is our idempotency key store fail-open?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "POP answers queries from a disk snapshot that can be a day old, and the health probe considers it healthy the moment it answers anything. work through what readiness should mean for us — zone currency, per-zone or per-POP, and what we do about zones that are never current by any strict definition — knowing the load balancer's probe is a TCP check we don't control", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "recommender is one nine-hundred-line object that legal has to read for the licensing filter and the data team has to change weekly for everything else. before splitting it i'd like agreement on the boundaries and on what evidence we need that the split changed no recommendations, given the output is inherently noisy this is the third time it's bitten us and i'd like it to be the last.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "nobody can tell me whether our idempotency store is fail-open, and the daily report duplication suggests it is. read the key store, the failover behaviour and the handler together, and tell me what happens to a request whose key lookup returns nil during a redis failover rather than an error i'd rather have the reasoning written down than a quick answer.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "i'd like an honest read on whether our shuffle can be fixed without changing what users think shuffle means, and then the implementation — a proper shuffled order per session with skips remembered", "purpose": "review", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "nightly recommender wrote half the usual rows and reported success, and the table it overwrites is the one the home screen reads at six in the morning. i want the validation story designed — what checks, where they run, what happens when one fails at four in the morning — rather than someone adding a row count assert and calling it done", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "zone timeline needs serial changes, transfers and config applies on one axis", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "recommendations went stale for a third of users and the pipeline says it succeeded:\n\n25/07/29 02:14:02 INFO DAGScheduler: Job 41 finished: saveAsTable at Recommender.scala:212, took 4118.882 s\n25/07/29 02:14:02 WARN TaskSetManager: Lost task 88 in stage 12.0: FetchFailed(BlockManagerId(41, ip-10-4-2-71), shuffleId=3)\n25/07/29 02:14:02 INFO DAGScheduler: Resubmitting stage 12 (retry 1)\n25/07/29 03:22:11 INFO DAGScheduler: Job 42 finished: saveAsTable, took 4088.114 s\n25/07/29 03:22:12 INFO Recommender: wrote 41,882,004 rows to recs.user_daily\n\nyesterday's run wrote 62 million rows; the table is overwritten, not appended, and the job exits zero either way", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "site photos taken offline disappear when the app comes back online, maybe one in fifty:\n\n[sync] 08:12:04 queued photo p_4471 (site 88, task 412) 4.1MB\n[sync] 08:12:04 queued photo p_4472 (site 88, task 412) 3.8MB\n[sync] 11:44:19 connectivity restored, draining queue (2 items)\n[sync] 11:44:20 uploading p_4471... 201 created\n[sync] 11:44:21 uploading p_4472... 413 payload too large\n[sync] 11:44:21 removing p_4472 from queue (non-retryable)\n[sync] 11:44:21 queue empty\n\nthe 413 comes from a gateway limit of 4MB that nobody documented, and non-retryable means we delete the local file", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "DNSSEC validation started failing for one zone and only from some resolvers:\n\ndig +dnssec example.com @8.8.8.8 → SERVFAIL\ndig +dnssec example.com @1.1.1.1 → SERVFAIL\ndig +dnssec example.com @our-pop-fra1 → NOERROR, AD not set\n\nzone signing:\n ZSK rolled 2026-07-28T02:00Z (prepublish, 24h overlap configured)\n DS record at the parent: still the pre-roll KSK digest\n RRSIG expiry on the SOA: 2026-07-29T02:00Z\n\nthe overlap was configured as 24 hours and the roll happened 26 hours before the old signatures expired", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "changelog for the mobile app release, which our users will read in the store listing:\n\n41c9e0b fix(shuffle): shuffle now plays every track before repeating\n88f21c0 fix(player): resuming from the lock screen keeps your position and track\nc0aa774 feat(offline): downloads survive an app update\n2e91b45 fix(sync): queued photos are no longer deleted when an upload is rejected\naa30f19 perf(library): library loads in under a second with 10,000 saved tracks\n9c1d004 chore: minimum iOS is now 17\n4410bb7 feat(player): crossfade between tracks, off by default\nb77e910 fix(a11y): the player controls are reachable with VoiceOver\n\nour readers are listeners, not engineers; two of these are the complaints we see most in reviews", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "unsere Offline-Warteschlange ist an drei Stellen implementiert:\n\n// TaskQueue.dart — eigene SQLite-Tabelle, FIFO, kein Retry-Limit\n// PhotoQueue.dart — Dateisystem plus JSON-Index, löscht bei 4xx\n// ReportQueue.dart — SharedPreferences, hält nur den letzten Bericht\n\ndrei Warteschlangen mit drei Fehlerbehandlungen, keine gemeinsame Sicht auf „was ist noch nicht gesendet\", und der Nutzer sieht keine davon\n\ngewünscht ist eine Warteschlange mit einheitlicher Semantik, ohne dass die App offline schlechter wird als heute\n\nZahlen aus dem letzten Monat:\n Aufgaben in der Warteschlange (Median pro Gerät): 14\n Fotos in der Warteschlange (Median pro Gerät): 31\n Berichte: 1 (nur der letzte wird gehalten)\n Einträge, die nach einem 4xx gelöscht wurden: 312\n Einträge, die der Nutzer je gesehen hat: 0\n\nund der relevante Code:\n\n if (e.statusCode >= 400 && e.statusCode < 500) {\n await _queue.remove(item);\n await File(item.path).delete();\n }", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "design spec for the field app's sync status screen, which currently doesn't exist:\n\nSync status\n- A persistent indicator in the app bar: synced, syncing with a count, offline with a count, or attention needed.\n- The screen itself lists pending items grouped by type — tasks, photos, reports — with size and age.\n- An item that failed shows why in plain language and what the user can do, never a status code alone.\n- Photos that cannot be uploaded because of size offer to resize and retry rather than being discarded.\n- A conflict shows both versions side by side with the author and time of each, and requires an explicit choice.\n- Nothing is ever deleted from the queue without the user seeing it; \"discard\" is an action, not a consequence.\n- Must be usable in gloves, in sunlight, on a cracked screen, which is the actual condition of most site tablets.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "el botón de descarga no muestra progreso", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "es"}
{"prompt": "task list targets are 36dp outdoors", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "track titles clip at large type", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "licensing filter out of the recommender", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "doc comments on the edge config API", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "player screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "offline sync loses concurrent edits silently and a customer is threatening not to renew over it, which makes the conflict model a commercial question rather than a technical preference. lay out the options — server clocks, per-field versioning, a CRDT for the notes field — with the team's lack of CRDT experience and a full working day offline as the constraints", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "we need a plan for POPs in regions where we cannot ship our own hardware", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "cache key configuration honours whatever Vary the origin sends with no cap on variants, which let one customer's one-line change multiply our key space by every user agent on the internet. read the key construction and the override table and tell me what other single-line customer changes could do something similar nobody has trusted this code for about a year, which is part of the problem.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "before we change the sync model i want the conflict semantics written down — what's a conflict, who wins, what the user sees, what we keep for the audit trail — and then the per-field versioning implemented against it, starting with the notes field that people actually fight over", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "POP readiness needs a definition and a first implementation. work through what \"current\" means per zone class with me, then wire a readiness endpoint the load balancer can use, keeping enough capacity during rolling deploys", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "three definitions of \"downloaded\" should become one, and i'd like to know which of the three the library screen should have been using before we standardise. check that against what users report, then unify", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "is the overwrite mode leaving the recs table empty while the job runs", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "what guarantees does the nightly job make about the table between the truncate and the write", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "recommender should write to a new partition and swap rather than overwriting in place", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "nobody can tell me what happens to a queued daily report when the user logs out on site before it syncs — whether it survives, whether it uploads under the next user, or whether it quietly disappears. trace it through the queue, the auth layer and the local database, and tell me which of those three it actually is", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand what our POP actually does with a query for a zone it has never successfully transferred — whether it serves the snapshot, refuses, or falls through to another POP — because the answer decides whether readiness is a real problem or a cosmetic one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "playlist shuffle repeats the same tracks far more than users expect, and they're right:\n\nsample of one user's session, 40-track playlist, shuffle on:\n positions played: 12, 4, 12, 31, 4, 12, 7, 31, 12\n distinct tracks in first 9 plays: 5\n\nour shuffle picks a random index per track with a seed derived from the playlist id and the day, and skips are not remembered, so pressing next re-rolls from the same seed and lands on the same handful", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "so the field app's task list shows different data to two users on the same site:\n\nuser A (foreman, online since 06:00): 41 tasks, last sync 11:02\nuser B (engineer, offline 07:00-11:30): 38 tasks, last sync 11:31\ntasks created by user A at 09:14 and 09:41 are missing for user B\ntask edited by user B offline at 10:02 overwrote user A's 09:41 edit on sync\n\nour sync is last-write-wins on the whole task record, using the device clock, and user B's tablet is 4 minutes fast", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "the enterprise construction customer's requirements, which arrived with a signing date:\n\n\"Field data captured offline must not be lost or silently overwritten under any circumstance, including device clock error and concurrent editing. The application must show the user what is pending upload. Data must be retained in the customer's region. Site photographs are contractual evidence and must be retained for six years with an audit trail of any modification. The supplier must demonstrate recovery from a device lost mid-project with no data loss beyond what was captured on that device since its last sync.\"\n\nwe currently fail four of those five. i want the plan by contractual exposure, not by engineering preference", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "our runbook for a stale-serving POP is \"restart it\", which is what caused the last incident. reality:\n\n- symptom is one POP answering with an old serial after a deploy or a restart\n- `edgectl zone status --pop fra1` shows the serial and the source (disk, xfr or cache)\n- draining the POP is safe and takes about 30 seconds to take effect at the load balancer\n- restarting it without draining first means it serves the disk snapshot again, which is the original problem\n- the disk snapshot is refreshed hourly, so a POP that has been down for a day has a day-old zone\n- forcing a transfer with `edgectl zone xfr --pop fra1` takes 60-120s for the large zones\n\nwrite the runbook, ordered by what someone paged would need first", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "field app has three offline queues with three storage mechanisms and three failure behaviours, only one of which retries. unify them behind one queue with one semantics, keep the app working offline for a full day exactly as it does now, and make sure a migration doesn't drop anything already queued on a device assume whoever picks it up next has no context beyond what you write.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "a third of users got yesterday's recommendations and the job reported success, having written 41 million rows where the previous night wrote 62 million. work out how a partial write becomes a success before we add any checks, because the answer determines whether the fix is validation or the write path itself", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "the label's delivery spec, which we ingest from:\n\ndaily DDEX feed over SFTP, one batch per label per day\n each batch is a zip of XML messages plus audio files, up to 40GB\n a message can update or withdraw a previously delivered release, referenced by its DDEX party and release id\n withdrawals must take effect within 24 hours, contractually, including removing tracks from playlists and recommendations\n territory rights are per track per territory with start and end dates, and can change retroactively\n a malformed message in a batch must not block the rest of the batch\n the label sends corrections as full re-deliveries, so idempotency is on (party, release_id, message_timestamp)\n\nbuild the ingestion; the withdrawal path is the one legal cares about", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "one offline queue, three item kinds", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "edge console is the thing we open during an incident and it currently shows a spinner when the control plane is unreachable, which is exactly when we need it. rebuild the zone view to the spec, rendering from cache with an age indicator, and make a POP on the wrong serial impossible to miss", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "our spark configuration versus the shape of the new grouping key:\n\nspark.sql.shuffle.partitions: 200\nspark.executor.memory: 16g\nspark.executor.cores: 4\nspark.executor.instances: 40\nspark.sql.autoBroadcastJoinThreshold: 10m\nspark.sql.adaptive.enabled: false\n\ndistinct (user_id): 41 million\ndistinct (user_id, context_id): 1.6 billion\noutput rows: about 200 per key, collected into a list before slicing\n\nand what the stage looked like when it failed:\n\n Stage 12: 200 tasks, 188 succeeded, 12 failed with OOM\n shuffle read per task: p50 412 MB, max 8.1 GB\n spill (memory): 2.4 TB total\n spill (disk): 1.1 TB total\n peak execution memory per task: 14.2 GB against a 16g executor\n\nthe skew is real: the largest (user_id, context_id) key has 4.1 million events, and the median has eleven", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "field app ignores the tokens and uses 36dp targets with 14px body text, on tablets used outdoors in gloves. bring it onto the tokens, and tell me how much less fits on screen once the type and targets are right", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "a customer's cache hit rate fell from 94% to 41% after they added User-Agent to Vary, and our origin took the difference. confirm that's the whole story, then add the guard rail that warns or caps before it happens again", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "`Zone.current` means \"loaded from somewhere\" in the resolver and \"matches the primary's serial\" in the admin module, which is precisely the ambiguity behind the stale-serving incident. give the two concepts different names throughout, and make the resolver's check the stricter one wherever that doesn't cost us availability", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "nightly recommender needs an output contract before it needs more checks. define what a valid run means — row counts, key coverage, comparison against yesterday — then implement the swap-a-partition write so a bad run can't overwrite a good one", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "one track model across the services", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "edge config API reference needs writing, and while you're in there confirm whether a validation failure on one POP really does leave the config applied on the others, because our support team has been telling customers otherwise", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "seit dem Update spielt die App nach dem Sperrbildschirm den falschen Titel weiter:\n\n[player] 18:41:02 now playing track=t_4471 position=124.4s queue_index=3\n[player] 18:44:11 app entered background\n[player] 18:44:12 remote command center: nowPlayingInfo updated (track=t_4471)\n[player] 19:02:44 remote command: play\n[player] 19:02:44 resuming queue_index=3 position=0.0s track=t_4488\n\nder Queue-Index wird beim Reaktivieren neu aufgelöst, und die Queue wurde zwischenzeitlich vom Server neu gemischt; die Position geht dabei ebenfalls verloren", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
{"prompt": "ok so our spark job's memory profile changed after the schema evolution and now it fails at the same stage:\n\n25/07/29 04:11:02 ERROR Executor: Exception in task 412.0 in stage 12.0\njava.lang.OutOfMemoryError: GC overhead limit exceeded\n\tat org.apache.spark.sql.catalyst.expressions.codegen.BufferHolder.grow(BufferHolder.java:71)\n\tat org.apache.spark.sql.execution.aggregate.HashAggregateExec$$anon$1.processInputs\n\nexecutor memory 16g, 4 cores, spark.sql.shuffle.partitions 200\nthe grouping key was (user_id) and is now (user_id, context_id), which multiplies the distinct key count by about forty", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "honestly the construction app's daily report submits twice when the site has patchy signal:\n\n11:02:14 POST /v1/reports (idempotency-key: local-4471) → timeout after 30s\n11:02:44 POST /v1/reports (idempotency-key: local-4471) → 201 created id=r_88412\n11:03:14 POST /v1/reports (idempotency-key: local-4471) → 201 created id=r_88413\n\nserver side:\n idempotency keys are stored per user with a 10 minute TTL in redis\n the first request completed on the server at 11:02:47, after the client had already timed out\n redis was failing over between 11:02:40 and 11:02:50, and lookups during a failover return nil rather than an error", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "right, our shuffle implementation, which users describe as broken and i suspect is worse than that:\n\ndef nextTrack(playlist: Playlist, user: User): Track = {\n val seed = playlist.id.hashCode ^ LocalDate.now().hashCode\n val rng = new scala.util.Random(seed)\n val idx = rng.nextInt(playlist.tracks.size)\n playlist.tracks(idx)\n}\n\ncalled once per skip and once per track end, no memory of what has been played, and the seed is stable for the whole day so the same sequence recurs every session", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "quick one — the zone loading path at POP startup, which is why we serve stale answers after a deploy:\n\nfn start(&self) -> Result<()> {\n let snapshot = self.disk.load_latest()?; // may be up to 24h old\n self.serve(snapshot); // start answering immediately\n tokio::spawn(async move {\n let zone = self.primary.axfr().await?; // can take 60-120s for large zones\n self.serve(zone);\n Ok::<_, Error>(())\n });\n Ok(())\n}\n\nhealth checks pass as soon as we answer anything, the load balancer adds us immediately, and there is no readiness signal tied to the transfer completing", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "por favor, revisa el trabajo de spark antes de que lo dejemos correr esta noche:\n\nval recs = events\n .filter($\"ts\" > lit(cutoff))\n .groupBy($\"user_id\", $\"context_id\")\n .agg(collect_list(struct($\"track_id\", $\"score\")).as(\"items\"))\n .withColumn(\"items\", slice(sort_array($\"items\", false), 1, 200))\n\nrecs.write.mode(\"overwrite\").saveAsTable(\"recs.user_daily\")\n\ncollect_list acumula en memoria por clave, la cardinalidad de (user_id, context_id) es unos 1.600 millones, y el modo overwrite borra la tabla antes de escribir", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "es"}
{"prompt": "fyi the idempotency design note for the field API, written before we had offline devices:\n\n## Idempotency\nClients send an Idempotency-Key header. The server stores the key with the response for ten minutes and replays the stored response on a repeat.\n\n## Assumptions\n- A client retry happens within ten minutes.\n- The key store is available; a failed lookup means the key is new.\n- Keys are unique per user.\n\n## Not covered\nClients that queue for hours offline. Key store failover. Two devices submitting the same queued item.\n\nour field app queues for up to a working day, and a nil lookup during a redis failover is treated as \"new\"", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
{"prompt": "heads up: the query behind our artist dashboard, which times out for anyone in the top thousand:\n\nSELECT t.id, t.title,\n sum(p.count) AS plays,\n count(distinct p.user_id) AS listeners,\n (SELECT sum(count) FROM plays_daily p2 WHERE p2.track_id = t.id AND p2.day > current_date - 28) AS plays_28d,\n (SELECT count(*) FROM playlist_tracks pt WHERE pt.track_id = t.id) AS in_playlists\nFROM tracks t\nJOIN plays_daily p ON p.track_id = t.id\nWHERE t.artist_id = $1 AND p.day > current_date - 365\nGROUP BY t.id, t.title\nORDER BY plays DESC;\n\nplays_daily is 41 billion rows partitioned by day, playlist_tracks is 12 billion, and a top artist has 4,000 tracks", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "small thing but the photo upload path in the field app, which is deleting people's evidence:\n\nFuture<void> _drain() async {\n for (final item in await _queue.items()) {\n try {\n await _api.upload(item);\n await _queue.remove(item);\n await File(item.path).delete();\n } on ApiException catch (e) {\n if (e.statusCode >= 400 && e.statusCode < 500) {\n await _queue.remove(item); // \"non-retryable\"\n await File(item.path).delete(); // and the local copy goes too\n }\n }\n }\n}\n\na 413 from an undocumented gateway limit lands squarely in that branch, and site photos are the evidence for variation claims worth thousands", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "support's notes on the missing site photos, which need to become a customer explanation:\n\n- photos taken offline are queued locally and uploaded when the device reconnects\n- an upload rejected with a 4xx is treated as permanently failed and the local copy is deleted\n- a gateway limit of 4MB, which we never documented, rejects photos from newer phones\n- affected users see the photo in the app until the sync runs, then it disappears with no message\n- we can recover nothing; the local file is gone\n- about 300 photos across 40 sites in the last month, some attached to variation claims\n\nwrite the customer notification and the internal note, and be clear that the data is not recoverable", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "incident notes from the DNSSEC failure, and we owe the customer a report:\n\n02:00 ZSK roll executed by the scheduled job\n04:11 first SERVFAIL reports from users on validating resolvers\n04:40 on-call confirms the old RRSIGs expired 26 hours after the roll, overlap configured as 24\n05:02 emergency re-sign with the previous key, published\n05:20 propagation to all POPs complete\n06:15 validating resolvers recover as their caches expire\n08:00 impact assessed: the zone was unresolvable for validating resolvers for about two hours, roughly 40% of their traffic\n\nthe customer runs a payments API on that zone and wants to know why an automated key roll can take a zone off the internet", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "as notas da reunião sobre a sincronização offline, para transformar em documento de decisão:\n\n- o modelo atual é last-write-wins sobre o registo inteiro, com o relógio do dispositivo\n- os tablets em obra estão frequentemente vários minutos desacertados\n- edições concorrentes ao campo de notas perdem-se sem qualquer aviso\n- opções: relógio do servidor, versões por campo, ou CRDT para o campo de texto\n- a equipa não tem experiência com CRDTs e a app tem de continuar a funcionar offline durante um dia inteiro\n- os clientes já perderam registos e um deles ameaça não renovar\n\nescreve a nota de decisão com as opções, o esforço estimado e uma recomendação", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "pt"}
{"prompt": "not urgent, but the questions from a customer's architecture review, which need answering as a document:\n\n\"What happens to our traffic if one of your POPs is unhealthy but still announcing? How do you roll back a configuration change that is already live in some locations? Is a zone transfer authenticated, and what prevents a compromised POP from serving forged answers? What is your DNSSEC key rollover procedure and who approves it? If we misconfigure something catastrophically, what is the fastest path to reverting, and can we do it without your support team?\"\n\nanswer each from the code and the runbooks, and mark clearly where the answer is \"a human notices\" rather than a mechanism", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "社内向けに、レコメンドのバッチ運用ドキュメントがありません。現状は次の通りです:\n\n- 毎晩 02:00 に Spark ジョブが起動し、recs.user_daily を overwrite モードで書き換える\n- 途中でステージが失敗しても再試行され、最終的に成功すれば終了コードは 0 になる\n- 書き込み行数の下限チェックがないため、半分の行数でも「成功」として扱われる\n- 前日のテーブルは overwrite で消えるため、ロールバックできない\n- 実行時間は通常 70 分、遅い日は 3 時間、02:00 開始で 06:00 の配信に間に合わないことがある\n- 監視は Airflow のタスク成否のみで、出力の妥当性は誰も見ていない\n\n設定:\n\n spark.sql.shuffle.partitions = 200\n executor.memory = 16g\n executor.cores = 4\n\n社内向けの運用ドキュメントとしてまとめてください。特に「成功」の定義が曖昧な点を明確に\n\n直近 7 日の実行結果:\n\n 日付 行数 実行時間 終了コード\n 07-23 62,104,882 72 min 0\n 07-24 61,882,004 74 min 0\n 07-25 62,001,118 70 min 0\n 07-26 61,904,412 118 min 0\n 07-27 62,114,008 81 min 0\n 07-28 62,088,441 77 min 0\n 07-29 41,882,004 187 min 0 <- 誰も気づかなかった\n\n spark.sql.adaptive.enabled = false (2023 年に誰かが無効化)", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "ja"}
{"prompt": "genuinely puzzled by this: the field app's offline documentation, which is currently a paragraph in the sales deck:\n\nwhat actually happens offline:\n tasks, photos and daily reports are queued locally with no size limit\n the queue drains in order when connectivity returns, oldest first\n a 4xx response deletes the queued item and its local file\n conflicts resolve last-write-wins by device clock, silently\n downloads of drawings expire after 30 days and re-download on next connection\n the queue is not visible to the user; there is no \"3 items pending\" indicator anywhere\n\nwrite the documentation for site staff and their IT departments, honestly, because they plan their day around what this app can do without signal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "scalafix and scalac warnings on the recommender, gate goes on next sprint:\n\n[warn] Recommender.scala:88:22: match may not be exhaustive. It would fail on: Context.Unknown\n[warn] Recommender.scala:141:9: discarded non-Unit value\n[warn] Features.scala:41:13: method collectList in class Dataset is deprecated\n[warn] Shuffle.scala:22:5: parameter value seed in method nextTrack is never used\n[warn] Pipeline.scala:212:7: local val cutoff is never used\n\n5 warnings, and Shuffle.scala's unused seed parameter is interesting given users say shuffle is broken", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "clippy and cargo audit on the edge server:\n\nwarning: this async block may hold a lock across an await\n --> src/zone/store.rs:141:9\nwarning: large future (8.2 KB) may cause stack overflow when boxed\n --> src/resolver/handler.rs:88:1\nwarning: `unwrap` on a `None` value is possible here\n --> src/dnssec/keys.rs:41:22\n\ncargo audit:\n Crate: ring 0.17.7\n Advisory: RUSTSEC-2026-0044 (panic on malformed signature input)\n Solution: upgrade to >=0.17.12\n\nthe ring advisory is in the code path that validates DNSSEC signatures on inbound transfers", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "for context, the gateway limits versus what our own app sends:\n\ngateway:\n client_max_body_size: 4m # undocumented, set in 2023\napp (flutter):\n photo quality: 90, max dimension 4032 # about 3-8MB per photo on recent phones\n no client-side resize\napi docs:\n \"photos may be up to 25MB\"\nCDN in front of the gateway:\n max body 100MB\n\nthe 4MB limit is the effective one and nothing in the product tells anyone about it\n\nand the numbers from the last month:\n photos queued: 41,882\n photos rejected with 413: 312\n photos rejected and deleted locally: 312\n average size of a rejected photo: 6.4 MB\n sites affected: 40\n\nnothing in the app, the docs or the API response mentions four megabytes anywhere", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
{"prompt": "background: the DNSSEC signing config, and one number is why a zone went dark:\n\nsigning:\n algorithm: ECDSAP256SHA256\n zsk_rollover: prepublish\n zsk_lifetime_days: 30\n zsk_overlap_hours: 24\n rrsig_validity_hours: 26\n rrsig_refresh_hours: 20\n ksk_rollover: manual\n\nthe overlap is shorter than the signature validity, so signatures made with the outgoing key can outlive the period during which we publish it\n\nthe timeline the numbers produce:\n T+0h ZSK roll, new key published, old key still published\n T+24h old key unpublished (overlap expires)\n T+26h signatures made with the old key expire\n\nso for two hours there are live signatures whose key is no longer published, and every validating resolver returns SERVFAIL for the whole zone during that window", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
{"prompt": "worth a look — the iOS player's audio session setup, which i think is behind the lock screen bug:\n\ntry AVAudioSession.sharedInstance().setCategory(.playback, mode: .default, options: [])\ntry AVAudioSession.sharedInstance().setActive(true)\n\nMPRemoteCommandCenter.shared().playCommand.addTarget { [weak self] _ in\n self?.player.play() // resolves the queue index freshly\n return .success\n}\n\nMPNowPlayingInfoCenter.default().nowPlayingInfo = [\n MPMediaItemPropertyTitle: track.title,\n MPNowPlayingInfoPropertyElapsedPlaybackTime: player.currentTime\n]\n\nnowPlayingInfo is set once when playback starts and never updated, and the queue can be reordered by the server while the app is backgrounded", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
{"prompt": "les seuils d'alerte de la plateforme edge, on nous réveille pour rien :\n\n- alert: PopUnhealthy\n expr: up{job=\"pop\"} == 0\n for: 1m\n labels: { severity: page }\n\n- alert: CacheHitRate\n expr: cache_hit_ratio < 0.8\n for: 15m\n labels: { severity: ticket }\n\n- alert: ZoneSerialMismatch\n expr: count(count by (serial) (zone_serial)) > 1\n for: 0m\n labels: { severity: ticket }\n\nen réalité : un POP est toujours en maintenance quelque part ; la chute du taux de cache d'un client a doublé la charge origine sans réveiller personne ; et la divergence de serial après chaque déploiement produit un ticket que tout le monde ignore, y compris le jour où elle a duré deux heures", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "fr"}
{"prompt": "this pipeline object does feature building, model scoring, filtering and writing in one class:\n\nobject Recommender {\n def run(spark: SparkSession, cutoff: Timestamp): Unit = {\n // reads three source tables with different freshness expectations\n // builds features inline, with the window sizes as literals\n // scores with a model loaded from a hardcoded S3 path\n // applies business filters: explicit content, regional licensing, artist blocks\n // collects per user, slices to 200, writes with overwrite\n // no row count check, no comparison against yesterday, exits zero on any completed run\n }\n}\n\n900 lines, and the licensing filter is the part legal asks about", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "quarter planning input, and it needs sequencing:\n\n- the field app deletes site photos on a 4xx, which has already cost a customer a variation claim\n- offline sync loses concurrent edits silently and a customer is threatening not to renew\n- a DNSSEC roll took a customer's zone off the internet for two hours\n- the recommender wrote half the usual rows and nobody noticed for a day\n- shuffle is the top complaint in app store reviews and has been for a year\n- one Rust engineer on the edge platform, two on the field app, and the data team is three\n- there's an enterprise construction customer signing in november whose security review starts next month", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "architecture ticket, thinking before code:\n\nEDGE-220 — Readiness and zone freshness\nA POP currently answers as soon as any zone is loaded from its on-disk snapshot, which can be a day old, and the health probe reports healthy at that point. The proposal is a readiness signal tied to zone currency, so a POP does not receive traffic until its zones are current. Concerns: a POP with a very large zone takes two minutes to transfer and we would lose capacity during rolling deploys; \"current\" is ambiguous for zones that change every few seconds; some customers' zones are never current by that definition; and the load balancer's health check is a simple TCP probe we do not control.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "spec for the edge console's zone view, which we open during incidents:\n\nZone view\n- Per-POP table: serial being served, source (disk, transfer, cache), age, query rate, error rate. Sorted by staleness.\n- A POP serving a serial other than the current one is unmistakable — not a colour alone, and with the age in words.\n- Deployment strip: the last five config deployments with their status per POP, and which one a given POP is running.\n- One-click drain and undrain per POP, with a confirmation that states how much traffic will move and where.\n- A zone-level timeline of serial changes, transfers and config applies on one axis, because correlating those is the whole job.\n- The view must render from cached data with an age indicator when the control plane is unreachable, which is exactly when we need it.\n- Everything must be legible on a phone at 3am.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "accessibility findings for the music app's player, from an app store review and our own audit:\n\n1. The play/pause button's accessible label does not change with state.\n2. The scrubber is a custom control with no adjustable trait, so VoiceOver users cannot seek at all.\n3. Track changes are not announced, so a blind user cannot tell what is playing without navigating to the label.\n4. The queue reorder handles have no accessibility actions; reordering requires a drag.\n5. Album art has no alt text, not even the album name.\n6. The mini player and the full player expose duplicate elements to VoiceOver, doubling every swipe.\n7. Dynamic Type above the default clips track titles rather than truncating them, hiding the artist entirely.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "design tokens versus what the field app actually uses:\n\ntokens:\n color.surface #FFFFFF / #12151A\n color.text #12151A / #E9EDF2\n color.muted #5C6672\n color.status.ok #1A7F37\n color.status.warn #9A6700\n color.status.err #B42318\n space 4/8/12/16/24/32, radius 8/12, touch target 48dp (site gloves)\n type: title 20/28, body 16/24, caption 14/20\n\nthe field app: nine hardcoded colours, touch targets of 36dp on the task list, body text at 14px which is unreadable in sunlight, and status shown by colour alone on a screen people use outdoors\n\nbring it onto the tokens, fix the targets and the type sizes, and give status a non-colour indicator", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "gateway body limit to 25MB", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "ring bump for the DNSSEC path", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "store listing still says \"Beta\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "turn adaptive query execution back on", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "ZSK overlap longer than signature validity", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "client-side resize before photo upload", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "row count floor on the nightly job", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
{"prompt": "CacheHitRate should page, not ticket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "cap Vary variants per cache key", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "the schema we agreed for the offline queue, now it needs building on both sides:\n\nCREATE TABLE pending_items (\n id uuid PRIMARY KEY,\n device_id text NOT NULL,\n user_id uuid NOT NULL,\n kind text NOT NULL CHECK (kind IN ('task','photo','report')),\n payload jsonb NOT NULL,\n local_path text,\n created_at timestamptz NOT NULL,\n attempts int NOT NULL DEFAULT 0,\n last_error text,\n state text NOT NULL CHECK (state IN ('pending','sent','failed','conflict'))\n);\n\nnothing leaves the queue without the user seeing it; a 4xx moves an item to failed with a human-readable reason rather than deleting it; a conflict is a first-class state; and the queue survives an app update and a device restore", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "our POP has three code paths that decide whether to answer a query:\n\n// resolver/handler.rs\nif zone.is_loaded() { answer(zone) } else { servfail() }\n\n// health/probe.rs\nfn healthy(&self) -> bool { self.zones.any_loaded() } // any zone at all\n\n// admin/status.rs\nfn status(&self) -> Status { if self.zones.all_current() { Ready } else { Degraded } }\n\nthe resolver answers from whatever is loaded, the health probe reports healthy if any zone is loaded, and only the admin status knows whether the data is current — and nothing acts on it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
{"prompt": "field app has two HTTP clients, one with token refresh and one without, and the photo uploader uses the one without — which means a long offline period ends with an upload that 401s and gets treated as permanently failed. move everything onto the refreshing client, and check what else uses the wrong one", "purpose": "refactor", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "a walkthrough of how a play event becomes a recommendation would help before i touch features", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "the sync thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "nowPlayingInfo wird nie aktualisiert", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
{"prompt": "unused seed parameter in nextTrack", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "pending count in the app bar", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "conflicts need a side-by-side view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "scrubber needs the adjustable trait", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
{"prompt": "曲が変わっても読み上げられません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
{"prompt": "album art has no alt text", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "mini player duplicates VoiceOver elements", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "une seule notion de « zone à jour »", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "fr"}
{"prompt": "`serial` naming across the POP code", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "extract the queue drain from the sync service", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "inline `isDownloaded`, one caller now", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "changelog for the mobile release", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "nota aos clientes sobre as fotos perdidas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "pt"}
{"prompt": "document what \"deployment complete\" means", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
{"prompt": "summarise the readiness proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "PR body for the shuffle rewrite", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "can a 4xx delete a site photo?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "¿el job puede escribir la mitad de las filas?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "walk me through the zone transfer path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "why does shuffle repeat so much?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "site photos disappear after sync", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "recommendations are a day stale", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "one POP serves yesterday's zone", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "warum verliert die App Offline-Änderungen?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "de"}
{"prompt": "press ahead", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "more reliable", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "your judgement on the order", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
{"prompt": "lo del POP, sigue", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "es"}
{"prompt": "leave it tidier than you found it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
{"prompt": "same as we did before", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "doc for the review", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "nothing that touches prod", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
{"prompt": "second opinion 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": "whatever's next", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
{"prompt": "DNSSEC key roll took a customer's zone off the internet for two hours because the publication overlap was shorter than the signature validity. beyond fixing the number, i want a position on how key material changes are reviewed and rolled out at all, given this one was fully automated and nobody looked at it until resolvers started failing", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
{"prompt": "runbook for a stale POP currently says restart it, which is precisely what makes it serve the old snapshot again. write the real procedure — drain first, check the source, force a transfer, wait — in the order someone paged at three in the morning would need, and say why the obvious action is wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "idempotency design note assumes retries happen within ten minutes and that a failed lookup means a new key, both of which are false for a field app that queues for a working day. read it against the implementation and tell me which other assumptions have quietly stopped holding tell me if this is the wrong shape entirely, i won't be offended.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "track model exists three times with different field sets and hand-written conversions in six places, three of them lossy for multi-artist tracks. converge on one model with explicit conversions at the service boundaries, and prove that the mobile API's payloads are byte-identical for a sample covering the lossy cases the sooner we know roughly how big this is, the better for planning.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "cache key construction is split across a config parser, a request handler that ignores two fields of the parsed spec, and a production-only override table with forty-one entries nobody can explain. bring it into one place, work out which overrides are still load-bearing, and keep every customer's effective cache key unchanged unless we decide otherwise deliberately", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "sync status screen doesn't exist, which is why site staff discover a failed upload days later when someone asks for the photo. build it to the spec — pending items by type, plain-language failures, resize-and-retry for oversized photos, conflicts with an explicit choice — and make sure nothing leaves the queue invisibly", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "unsere Offline-Warteschlangen sollen zusammengeführt werden, aber vorher hätte ich gern ein Konzept, was garantiert nicht verloren gehen darf und was der Nutzer davon sieht. Danach die Umsetzung für die Foto-Warteschlange, weil dort bereits Daten verloren gingen", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "de"}
{"prompt": "DDEX ingestion needs the withdrawal semantics agreed before anything is built — what removing a release means for playlists, caches and recommendations within 24 hours. decide that with me, then implement the ingest and the withdrawal path", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "offline documentation has to exist before the enterprise security review, and writing it will surface things we should fix rather than describe — the silent deletion especially. write it, and give me that list separately", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "escribe la documentación del proceso de recomendaciones para el equipo de datos y comprueba en el código si el modo overwrite deja realmente la tabla vacía durante la escritura, porque eso explicaría los informes de la mañana", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "es"}
{"prompt": "our track model exists three times with different field sets:\n\n// api/TrackDto.scala — 41 fields, what the mobile app receives\n// domain/Track.scala — 22 fields, what the recommender uses\n// storage/TrackRow.scala — 38 fields, what the database has\n\nconversions are hand-written in six places, three of them lossy in ways that only show up for tracks with multiple artists, and the licensing fields exist in two of the three\n\nthe conversions, for reference:\n\n TrackDto.fromDomain(t: Track): TrackDto // drops secondary artists\n Track.fromRow(r: TrackRow): Track // drops licensing fields entirely\n TrackRow.fromDto(d: TrackDto): TrackRow // used only by the admin importer\n TrackDto.fromRow(r: TrackRow): TrackDto // the mobile read path, keeps licensing\n Track.fromDto(d: TrackDto): Track // used by the recommender's backfill\n TrackRow.fromDomain(t: Track): TrackRow // drops everything the domain doesn't model\n\nsix conversions, three lossy, and the licensing fields survive only two of the six paths", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
{"prompt": "stale-POP runbook should be a page rather than a wrong one-liner, and the restart command should refuse to run on an undrained POP. write the runbook, then add the guard", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "licensing filter should live somewhere legal can read it rather than inline in a nine-hundred-line object. extract it, then document the rules it encodes so the next licensing question doesn't require an engineer", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "POP's three notions of health should collapse into one. do that, and tell me whether any of the current callers depended on the loose definition — the admin status page especially", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "daily reports submit twice on patchy signal and the idempotency store looks fail-open during a failover. confirm the mechanism, then make the store fail closed and give the client a longer key lifetime for offline queues", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
{"prompt": "lock screen resumes the wrong track because the queue index is re-resolved after the server reshuffles. diagnose it properly, then make the player resume by track identity and position rather than by index", "purpose": "debugging", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "player fails seven accessibility items including a scrubber blind users cannot operate at all. fix them, and write the accessibility section for the store listing, which we've never had", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
{"prompt": "pending-items table needs its state machine agreed before it's built — what conflict means, what happens to a failed item the user ignores for a week. settle that, then implement both sides", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "is it expected that a config change is live on some POPs and not others for ninety seconds", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "pouvez-vous m'expliquer comment la file d'attente hors ligne gère une mise à jour de l'application ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "fr"}
{"prompt": "docs/sync.md claims conflicts are surfaced to the user, which has never been true", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "a short note on why we're moving to partition-swap writes, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "API changelog needs an entry for the photo size limit becoming documented and enforced", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "scaladoc on Recommender.run promises idempotency that the overwrite write mode doesn't provide", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "write the note to sites whose photos we lost, including what we can and cannot recover", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "health endpoint reports a POP healthy while it serves a zone from a day-old snapshot", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "how should we handle a customer zone that changes faster than we can transfer it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "i want a position on whether the field app should sync through a queue or a proper replicated store", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
{"prompt": "two labels want realtime delivery rather than a daily batch, what would that mean for ingestion", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "construction customers run four app versions and sites go months without updating", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "what should happen to a site's data when the project finishes and the contract ends", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "task list should show which items are pending upload rather than looking synced", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "artist dashboard should load progressively rather than waiting for the slowest query", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
{"prompt": "whatever the security review needs first", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "pick up the queue work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
{"prompt": "POP metrics are labelled by pop and zone, which for our largest customer alone is four million series and most of our monitoring bill. rework the labelling so per-zone detail is available on demand rather than always, and tell me which dashboards and alerts break when the high-cardinality labels go", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "recommender reads three source tables with different freshness guarantees and treats them all as current, which is probably why the cold-start features look wrong on mondays. make the freshness explicit at the read, and tell me which features are actually affected before we change any behaviour", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "iOS and Android players implement the queue independently and disagree about repeat-one, which users notice when they switch devices mid-session. decide which behaviour is correct with me first, since it's a product question, then align both clients", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
{"prompt": "photo uploads should be chunked so a large file on a site connection can resume rather than restarting, and we should agree the chunk size and the resume semantics before either side is built. settle that, then implement the server side", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "internal page on the recommendation pipeline stops at \"the nightly job writes the table\", which is why nobody knew a partial write was possible. write the page properly — the three source tables, the grouping, the filters, the write mode, and what \"success\" currently means — as the reference for the validation work", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt": "nightly job exits zero whether it writes sixty-two million rows or forty-one, and the table it overwrites is what the morning home screen reads. add a floor and a comparison against the previous run, fail loudly below it, and make sure the failure is visible to someone before six in the morning rather than after", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "three retry helpers exist in the scala codebase and the recommender uses none of them, having its own loop that retries a failed stage without checking whether the previous attempt left rows behind. consolidate onto one helper with explicit idempotency expectations, and tell me which callers were relying on the differences", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
{"prompt": "field app's drawing cache expires after thirty days and re-downloads on the next connection, including drawings that haven't changed, which on a site connection costs an hour and a lot of goodwill. make expiry depend on the drawing's version rather than the calendar, keeping offline availability exactly as it is", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "staging environment has one POP and production has forty-one, with the same zone transfer timeout and the same snapshot refresh interval, which is why the stale-serving behaviour has never once appeared before a release. bring the staging numbers into a defensible relationship with production and note which of them are genuinely per-POP", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
{"prompt": "app's photo quality setting produces files above the gateway's undocumented limit on any phone bought in the last three years, which is the actual cause of the deleted-evidence incident. lower the default, resize on the client before upload, and make sure existing queued photos are resized rather than rejected when the app updates", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "support needs an endpoint that returns a device's pending queue as the server understands it — what has arrived, what is duplicated, what was rejected and why — because today the only way to answer \"where did my photo go\" is to ask the customer to read their own screen back to us over the phone", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "drawing cache and the offline queue both decide independently when local storage is under pressure, and on a 64GB tablet halfway through a project they fight: the cache evicts drawings the queue is about to attach, and the queue's photos push the cache below its own floor. give storage one owner with an explicit budget per kind of data, and keep a full working day offline possible on the smallest device we support", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "edge config validation runs in three places — the console's form, the API on write, and each POP on apply — and they disagree enough that a config can pass the first two and be rejected by half the fleet. bring them onto one validator compiled into all three, and tell me which currently-live configs would fail it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
{"prompt": "before the enterprise security review i want a read on whether a compromised POP could serve forged answers for any customer zone, given that transfers are authenticated by source address and the signing keys live on the primaries. tell me what an attacker with one POP could actually do", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
{"prompt": "console's zone view refuses to render at all when the control plane is unreachable, which is the exact circumstance in which we open it. serve it from the last known state with a visible age, keep the drain controls working against the POPs directly, and make it obvious which parts of the page are stale", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "shuffle rewrite needs the product behaviour settled before the code: whether a shuffled order persists across sessions, what a skip means for the rest of the order, and whether adding a track reshuffles. decide that with me, then implement it in the shared player logic", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "zone transfers are authenticated by source address, which is how they were set up when we had three POPs in one datacentre and is now indefensible. move to TSIG or mutual TLS per POP, roll it out without a flag day across forty-one locations, and make an unauthenticated transfer attempt something we alert on rather than something we allow", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "nobody has been able to tell me how a withdrawn release actually leaves the product — whether it disappears from playlists immediately, waits for the nightly recommender, or lingers in the mobile app's local cache until eviction. trace it through ingestion, playlists, recommendations and the client caches, and tell me where the 24-hour contractual window is actually at risk", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "label ingestion accepts a batch as a unit, so one malformed message means the whole day's deliveries from that label sit unprocessed until someone notices. i want to know exactly how failures are currently isolated, if at all, and what a single bad message can hold up in the worst case we've actually seen", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
{"prompt": "library screen shows a track as downloaded when the file exists, regardless of whether the download record says it completed or the licence has since expired, which is why people find silent tracks on a plane. show the state honestly — complete, partial, expired — and make the offline case the one we design for rather than the exception", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "an endpoint that returns, for one zone, the serial each POP is currently serving along with where it came from and how old it is, so the console and the runbook stop depending on someone SSHing into a POP to find out. it has to answer while the control plane is degraded, which is when it matters", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "i'd like to understand what the mobile client does with a track whose licence expired while the device was offline — whether it refuses to play, plays anyway, or removes it silently — because the answer determines whether our territory rights handling is a client problem or a server one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the queue screen shows tracks with no indication of which are downloaded, which is the single thing people want to know before a flight, and the download state we do show elsewhere is unreliable anyway. show it honestly on the queue, including partial and expired, and make the offline case the default assumption rather than an edge case", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
{"prompt": "we need a per-zone deployment status endpoint that reports, per POP, which config revision is live rather than which one was acknowledged, since those are not the same thing and our console currently shows the second while claiming the first. it has to work when the control plane is degraded and be cheap enough for the console to poll", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
{"prompt":"Is there a cleaner way to separate OvertureWillowCodecStore's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"OvertureCopperBridgeCoordinator needs a paired pass: lay out a staged migration for OvertureCopperBridgeCoordinator, plus consolidate the duplicated normalization paths without changing behavior. Use projects/overture/Sources/App/SessionStore.swift as the source of truth, preserve the Room contract, and avoid unrelated cleanup.","purpose":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Bring OvertureSableParserService'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":"En projects/overture/services/ledger/replay.go, OvertureIrisBatchStore tiene un problema intermitente en el flujo de OpenTelemetry. Termina el layout responsive, estados vacío y retry, foco por teclado, dark mode y reduced motion.\n\nRestricciones:\n- seguir con OpenTelemetry\n- conservar compatibilidad y cancelación\n- limitar el cambio a OvertureIrisBatchStore","purpose":"frontendImpl","secondary":"debugging","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"es"}
{"prompt":"Worker: Incident timeline — INC-55117\n\n08:02 deploy OvertureAcornWidgetFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the OvertureAcornWidgetFlow 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":"SDK consumers are ready for durable continuation tokens, so the remaining work lives in OvertureMosaicGridService's API, storage, and worker layers. Wire the schema, repository, handler, and worker so duplicate deliveries return the original result and shutdown never acknowledges uncommitted work.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureMosaicGridService\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"OvertureMoonlitSDKCoordinator: the screen feels unfinished","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Please resist widening this one: OvertureOrbitSyncStore works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureOrbitSyncStore\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"OvertureAcornWidgetCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Security flagged OvertureCoralUploadStore for a read-only pass because its gRPC boundary mixes tenant data, retries, and cancellation in subtle ways. 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- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current gRPC operational envelope\n\nThis repository spans IoT fleet, Ruby, SolidJS; use its existing conventions rather than importing a new abstraction.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Two asks around OvertureCloudReconcilerCoordinator: (1) assess ownership and failure handling in projects/overture/lib/codec/frame.cc; (2) capture the contract and rollback note for consumers. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"This should remain a deliberately small patch: OvertureMarbleTokenService has one known configuration mistake in projects/overture/config/staging.toml, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to OvertureMarbleTokenService and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"OvertureMicaProfileCoordinator: polish the last piece","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"The data is already available in projects/overture/engine/render/atlas.cpp; render it as a sortable table with a compact mobile card fallback, visible focus, and honest loading placeholders.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Before we approve OvertureDeltaCanvasStore, assess whether a misleading timeout name used in five packages is an actual correctness risk or merely confusing structure.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"boundary","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about OvertureBeaconStoreStore, but the current prose in projects/overture/src/sync/reconcile.ts only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing FastAPI deployment\n- keep the work scoped to OvertureBeaconStoreStore and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"en"}
{"prompt":"We expect OvertureMapleQueueService to outgrow its current FastAPI arrangement next quarter, but changing everything at once would be risky. Propose the module boundaries and migration choreography, compare two viable approaches, and make the risk, cost, and reversibility tradeoffs explicit.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing FastAPI deployment\n- keep the work scoped to OvertureMapleQueueService and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Simulator: The OvertureEmberRelayFlow 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":"OvertureNimbusFormCoordinator: untangle the messy bit","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"Ticket OPS-55152: retire the legacy replay path for OvertureEchoRegistryCoordinator\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 OvertureEchoRegistryCoordinator 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":"projects/overture/ui/settings/PrivacyPane.tsx 里的 OvertureOspreyJobService 最近在 gRPC 流程中出现间歇性问题。 原因已经明确：只把 staging timeout 从 15 秒改成 30 秒，并调整对应 assertion。\n\n约束：\n- 继续使用 gRPC\n- 保持兼容性和取消语义\n- 改动只限于 OvertureOspreyJobService","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"zh"}
{"prompt":"For OvertureRainfallDBCoordinator, change OvertureRainfallDBCoordinator's known staging timeout from 15 to 30 seconds; once that is complete, give the existing implementation a read-only safety pass. Work from projects/overture/internal/auth/refresh.go, stay with OpenTelemetry, and preserve cancellation and back-pressure semantics. Keep the two outcomes separately reviewable.","purpose":"quickFix","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Runbook: Two asks around OverturePineMetricsCoordinator: (1) lay out a staged migration for OverturePineMetricsCoordinator; (2) then implement the bounded durable-cursor handler. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"planning","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"// projects/overture/app/src/main/SyncWorker.kt\nfinal class OvertureBasilRunnerFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate OvertureBasilRunnerFlow'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":"Ticket OPS-55132: retire the legacy replay path for OvertureTideWorkerFlow\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 OvertureTideWorkerFlow 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":"Could the reasoning behind OvertureLumenChartService's OpenTelemetry choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"OvertureQuartzPlayerCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Split OvertureCedarPolicyStore without behavior changes","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Two asks around OvertureHarborIndexCoordinator: (1) separate OvertureHarborIndexCoordinator's policy from transport without behavior changes; (2) capture the contract and rollback note for consumers. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Cadre la migration de OvertureHarborIndexStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"fr"}
{"prompt":"Could OvertureVelaDrawerFlow show the active OpenTelemetry 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":"Center the OvertureTideWorkerStore modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"en"}
{"prompt":"Read projects/overture/engine/render/atlas.cpp and tell me whether OvertureEmberRelayStore 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":"Architect a gradual ownership transfer for OvertureCinderAuthStore across two teams, including module seams, temporary interfaces, observability, handoff criteria, and rollback responsibility. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Investigate the OvertureCedarPolicyService hang","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Trace: Incident timeline — INC-55135\n\n08:02 deploy OvertureOspreyJobFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nCapture the OvertureOspreyJobFlow 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":"What does OvertureFernSnapshotService own?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"We need to move OvertureSpruceDaemonStore from the legacy store to Room. Propose phases, compatibility seams, metrics, rollback points, and the order in which clients should migrate; no code yet. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Diff: The OvertureBasilRunnerStore surface in projects/overture/apps/console/routes/usage.svelte is stable now; turn its edge cases into API documentation with one successful example and one cancellation example.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Bump OvertureRainfallDBService's timeout to 30s","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Fresh release brief for OvertureAmberFilterCoordinator:\n- primary outcome: separate OvertureAmberFilterCoordinator's policy from transport without behavior changes\n- companion outcome: capture the contract and rollback note for consumers\n- repository entry point: projects/overture/crates/index/src/segment.rs\n- platform constraint: Swift 6\n- known complication: an accessibility label that reads the internal enum\n\nBoth results are required, but they should remain independently reviewable. Preserve cancellation and back-pressure semantics; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"refactor","secondary":"writing","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Check OvertureQuartzPlayerStore's trust boundary","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"One contained cleanup in projects/overture/packages/api/openapi.yaml: remove the obsolete OvertureMarbleTokenStore import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Profiler: Two asks around OvertureOpalRouterCoordinator: (1) assess ownership and failure handling in projects/overture/cmd/exporter/main.py; (2) capture the contract and rollback note for consumers. Preserve cancellation and back-pressure semantics, and leave a clear boundary between the resulting artifacts or edits.","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"OvertureAtlasSearchCoordinator is blocking the next release because lost focus when the drawer animation finishes. I need two concrete outcomes from a single pass: lay out a staged migration for OvertureAtlasSearchCoordinator, and consolidate the duplicated normalization paths without changing behavior. Use the existing gRPC conventions in projects/overture/lib/codec/frame.cc; preserve cancellation and back-pressure semantics. 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":"planning","secondary":"refactor","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"En projects/overture/cmd/exporter/main.py, OvertureDriftConsoleService tiene un problema intermitente en el flujo de Room. Añade el endpoint idempotente con cursor durable, autorización tenant, spans y tests de retry.\n\nRestricciones:\n- seguir con Room\n- conservar compatibilidad y cancelación\n- limitar el cambio a OvertureDriftConsoleService Explicita los supuestos, señala la evidencia del repositorio y mantén compatibilidad con Room alrededor de OvertureDriftConsoleService.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"es"}
{"prompt":"In projects/overture/web/components/FilterDrawer.vue hat OvertureIrisBatchService ein sporadisches Problem im OpenTelemetry-Ablauf. Trenne Verantwortlichkeiten und entferne Duplikate, ohne API, Wire-Werte, Reihenfolge oder sichtbares Verhalten zu ändern.\n\nRandbedingungen:\n- OpenTelemetry weiterverwenden\n- Kompatibilität und Abbruchsemantik erhalten\n- Änderung auf OvertureIrisBatchService begrenzen Mache Annahmen explizit, nenne Repository-Belege und bleibe rund um OvertureIrisBatchService mit OpenTelemetry kompatibel.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"de"}
{"prompt":"Test Suite 'OvertureLedgerGateFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[OvertureLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/overture/crates/index/src/segment.rs:144: error: -[OvertureLedgerGateFlowTests 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 '-[OvertureLedgerGateFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nReconstruct the OvertureLedgerGateFlow 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":"Test Suite 'OvertureVelaDrawerCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[OvertureVelaDrawerCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/overture/internal/auth/refresh.go:144: error: -[OvertureVelaDrawerCoordinatorTests 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 '-[OvertureVelaDrawerCoordinatorTests 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\nBring OvertureVelaDrawerCoordinator's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-55113\n\n08:02 deploy OvertureOrbitSyncFlow 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. From this evidence, draft consumer-facing migration guidance for OvertureOrbitSyncFlow, plus a short operational recovery note. Keep uncertainty explicit and leave the implementation untouched.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.5,"slice":"pasted-context","lang":"en"}
{"prompt":"Any races in OvertureLedgerGateStore?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"thread 'tokio-runtime-worker' panicked at projects/overture/Sources/CLI/Commands/Doctor.swift: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: overturecopperbridgeflow::scheduler::LeaseTask::flush\n at ./projects/overture/Sources/CLI/Commands/Doctor.swift:217:18\n 4: overturecopperbridgeflow::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 OvertureCopperBridgeFlow 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":"The minimum supported OpenTelemetry version in projects/overture/internal/auth/refresh.go is one patch behind the lockfile. Align that single value and regenerate only the affected metadata.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"OvertureJuniperCLICoordinator: sequence, then polish","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"On compact widths, OvertureVelaDrawerStore's filter drawer should slide over the results, trap focus, and expose a visible close control without changing the desktop layout.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"How does OvertureSableParserStore propagate cancellation through the Swift 6 boundary, and are there code paths where ownership becomes ambiguous?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"For OvertureTideWorkerCoordinator, find the unknown cause of two validators with subtly different error strings; once that is complete, give the existing implementation a read-only safety pass. Work from projects/overture/crates/index/src/segment.rs, stay with Swift 6, and preserve cancellation and back-pressure semantics. Keep the two outcomes separately reviewable.","purpose":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Milestones for replacing OvertureTideWorkerService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"EXPLAIN (ANALYZE, BUFFERS)\nSELECT e.tenant_id, e.stream_id, max(e.sequence)\nFROM event_log e\nJOIN active_streams s\n ON s.tenant_id = e.tenant_id AND s.id = e.stream_id\nWHERE e.tenant_id = 't_55158'\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_55158'::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\nReconstruct the OvertureSummitProxyCoordinator 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":"OvertureOspreyJobCoordinator: clean up that old path","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"diff --git a/projects/overture/src/sync/reconcile.ts b/projects/overture/src/sync/reconcile.ts\nindex 62d71aa..90f3c1e 100644\n--- a/projects/overture/src/sync/reconcile.ts\n+++ b/projects/overture/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 OverturePineMetricsFlow 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":"2026-07-30T08:14:11.409Z level=info service=overtureslateeditorflow pod=overtureslateeditorflow-7cf8 request_id=55120 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=overtureslateeditorflow request_id=55120 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=overtureslateeditorflow request_id=55120 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=overtureslateeditorflow request_id=55120 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=overtureslateeditorflow request_id=55120 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=overtureslateeditorflow request_id=55120 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=overtureslateeditorflow request_id=55120 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=overtureslateeditorflow request_id=55120 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\nFind the source of this OvertureSlateEditorFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Our support and SDK teams keep answering the same questions about OvertureAtlasSearchService, but the current prose in projects/overture/engine/render/atlas.cpp only describes the happy path. Draft an ADR plus migration note that records the decision, rejected alternatives, compatibility window, observability signals, and the exact action required from consumers.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing gRPC deployment\n- keep the work scoped to OvertureAtlasSearchService and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"OvertureMicaProfileService needs an idempotent replay endpoint backed by FastAPI; accept a cursor, cap each page at 500 items, and return a stable continuation token.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Console: Could the reasoning behind OvertureEchoRegistryStore's Swift 6 choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Unify the OvertureQuartzPlayerService validators","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Assess the OvertureFernSnapshotStore diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Workspace: Ticket OPS-55131: retire the legacy replay path for OvertureCraneWorkspaceFlow\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 OvertureCraneWorkspaceFlow 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":"core","lang":"en"}
{"prompt":"Three teams extended OvertureMosaicGridStore independently, leaving parallel adapters and normalization branches that are supposed to behave identically. Separate those responsibilities into focused units, remove the duplicated normalization branches, and keep public types, wire values, log fields, timing, and test-observable behavior exactly the same.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current FastAPI operational envelope\n\nThis repository spans IoT fleet, Ruby, SolidJS; use its existing conventions rather than importing a new abstraction.\n\nThe target structure is settled; carry out the behavior-preserving edits rather than writing another strategy.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Em projects/overture/workers/thumbnail/consumer.ex, o OvertureOspreyJobStore tem um problema intermitente no fluxo de gRPC. Separe responsabilidades e remova duplicação sem mudar API, wire values, ordem ou comportamento observável.\n\nRestrições:\n- continuar com gRPC\n- preservar compatibilidade e cancelamento\n- limitar a mudança ao OvertureOspreyJobStore","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"pt"}
{"prompt":"Cadre la migration de OvertureFrostPanelService","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"fr"}
{"prompt":"Production says OvertureKiteSchedulerService is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. 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- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current gRPC operational envelope\n\nThis repository spans IoT fleet, Ruby, SolidJS; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Nobody is asking for code changes yet; we first need to understand whether the current OvertureEmberRelayService design actually guarantees what its callers assume. Follow one successful request and each early exit through the code, then rank findings by impact and state which apparent hazards are already ruled out by invariants.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureEmberRelayService\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"OvertureSlateEditorCoordinator: assess, then document","purpose":"review","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Draft OvertureBeaconStoreService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-55145: finish the compact OvertureCinderAuthFlow filter experience\n\nRoute: /catalog/search\nSource: projects/overture/workers/thumbnail/consumer.ex\nFramework: gRPC\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\n请根据以上上下文完成对应工作，保持 API、兼容性和 rollback，并明确说明证据和取舍。 Finish the visible OvertureCinderAuthFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Repository: diff --git a/projects/overture/pkg/cache/lease.rs b/projects/overture/pkg/cache/lease.rs\nindex 62d71aa..90f3c1e 100644\n--- a/projects/overture/pkg/cache/lease.rs\n+++ b/projects/overture/pkg/cache/lease.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\nRead the artifact above as a skeptical reviewer. Is OvertureAmberFilterFlow's current ordering, ownership, and cancellation behavior safe? Return findings with evidence, without editing files.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"OvertureWrenExportCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"UI ticket DES-55151: finish the compact OvertureWillowCodecCoordinator filter experience\n\nRoute: /catalog/search\nSource: projects/overture/web/components/FilterDrawer.vue\nFramework: OpenTelemetry\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible OvertureWillowCodecCoordinator state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Could the reasoning behind OvertureMoonlitSDKService's gRPC choices be captured as an ADR for engineers joining the project next quarter?","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"The behavior of OvertureSummitProxyService is stable, yet consumers are reconstructing its contract from tests, Slack threads, and scattered comments in projects/overture/Sources/CLI/Commands/Doctor.swift. Produce a reader-first guide that states the contract, calls out retries and cancellation, gives one copyable example, and separates operator advice from application-developer advice.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current Room operational envelope\n\nThis repository spans IoT fleet, Ruby, SolidJS; use its existing conventions rather than importing a new abstraction.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Incident timeline — INC-55146\n\n08:02 deploy OvertureLumenChartFlow 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\nReconstruct the OvertureLumenChartFlow 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":"Two engineers disagree about whether OvertureBirchMigratorService's cache is authoritative. Walk the reads and writes in projects/overture/config/staging.toml and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Pipeline: Incident timeline — INC-55111\n\n08:02 deploy OvertureIrisBatchFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nFind the source of this OvertureIrisBatchFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":"backendImpl","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"projects/overture/Sources/App/SessionStore.swift has grown through several launches, and OvertureSummitProxyStore now mixes policy, transport, persistence, and metrics in one place. Rename the overloaded state, extract the pure conversion work, and make dependencies explicit while preserving ABI, serialization, metrics, and failure messages.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing Room deployment\n- keep the work scoped to OvertureSummitProxyStore and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.\n\nThe target structure is settled; carry out the behavior-preserving edits rather than writing another strategy.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"Gateway: Incident timeline — INC-55115\n\n08:02 deploy OvertureCoralUploadFlow 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 OvertureCoralUploadFlow 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":"// projects/overture/engine/render/atlas.cpp\nfinal class OvertureAtlasSearchFlowCoordinator {\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\nWire OvertureAtlasSearchFlow's schema, storage, handler, and worker path so continuation is signed, duplicate delivery is stable, and shutdown cannot acknowledge uncommitted work.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-55116: retire the legacy replay path for OvertureWrenExportFlow\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 OvertureWrenExportFlow for durability, tenant isolation, races, and misleading observability. Separate blockers from questions and do not produce a patch.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Release engineering needs a OvertureSpruceDaemonService changelog entry that distinguishes operator action from invisible internal cleanup and names the rollback condition.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"OvertureFlintTimelineCoordinator: why is this odd","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Responsive layout for OvertureAcornWidgetService","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Renderer: projects/overture/Sources/App/SessionStore.swift now contains OvertureDeltaCanvasService's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"OvertureDriftConsoleStore'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":"OvertureRavenSessionService 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.6,"slice":"core","lang":"en"}
{"prompt":"OvertureBasilRunnerCoordinator: check the suspicious part","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Indexer: The OvertureMicaProfileStore 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":"Please resist widening this one: OvertureVelaDrawerService works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureVelaDrawerService\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.4,"slice":"boundary","lang":"en"}
{"prompt":"OvertureGarnetModalCoordinator: take care of the warning","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Rename OvertureSlateEditorService's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"OvertureBirchMigratorCoordinator: rethink this area","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"vague-eval","lang":"en"}
{"prompt":"Apparently: // projects/overture/apps/console/routes/usage.svelte\nfinal class OvertureGarnetModalFlowCoordinator {\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 OvertureGarnetModalFlow 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":"Please turn OvertureKiteSchedulerStore's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"OvertureNimbusFormService'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":"SDK consumers are ready for durable continuation tokens, so the remaining work lives in OvertureAmberFilterService's API, storage, and worker layers. Wire the schema, repository, handler, and worker so duplicate deliveries return the original result and shutdown never acknowledges uncommitted work.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureAmberFilterService\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Teach OvertureMarbleTokenFlow to verify signed continuation tokens, reject cross-tenant cursors, and rotate keys without invalidating tokens issued during the overlap window.","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"The data is already available in projects/overture/src/sync/reconcile.ts; 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":"Lately: // projects/overture/cmd/exporter/main.py\nfinal class OvertureJuniperCLIFlowCoordinator {\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 OvertureJuniperCLIFlow; 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":"Spell OvertureOpalRouterService's metric correctly","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"OvertureAmberFilterStore is functionally complete on desktop, but compact widths and assistive technologies still expose unfinished states. Finish the responsive layout, empty and retry states, keyboard order, VoiceOver labels, dark appearance, and reduced-motion transition while preserving the existing data-loading code.\n\nConstraints:\n- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current Swift 6 operational envelope\n\nThis repository spans IoT fleet, Ruby, SolidJS; use its existing conventions rather than importing a new abstraction.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"OvertureCinderAuthCoordinator: deal with the small issue","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-55153\n\n08:02 deploy OvertureDriftConsoleCoordinator 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 を維持し、根拠と判断を明確にしてください。 Capture the OvertureDriftConsoleCoordinator decision as an ADR with context, chosen behavior, rejected alternatives, compatibility window, and measurable rollback trigger.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.8,"slice":"boundary","lang":"en"}
{"prompt":"Oddly: # projects/overture/apps/console/routes/usage.svelte\n[worker.overturemosaicgridcoordinator]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.overturemosaicgridcoordinator.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.overturemosaicgridcoordinator.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.OvertureMosaicGridCoordinator.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-55159\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/overture/apps/console/routes/usage.svelte. Keep retry counts, shutdown grace, dependencies, formatting, and production values exactly as they are.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"pasted-context","lang":"en"}
{"prompt":"OvertureCraneWorkspaceCoordinator needs a paired pass: finish OvertureCraneWorkspaceCoordinator's responsive empty and retry states, plus capture the contract and rollback note for consumers. Use projects/overture/services/ledger/replay.go as the source of truth, preserve the OpenTelemetry contract, and avoid unrelated cleanup.","purpose":"frontendImpl","secondary":"writing","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"OvertureNovaPickerCoordinator: something is off here","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Add a bounded OvertureMapleQueueStore 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":"Ticket OPS-55140: retire the legacy replay path for OvertureMoonlitSDKFlow\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 OvertureMoonlitSDKFlow, 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":"Currently: Please turn OvertureMosaicGridFlow's existing tests into a short contract reference, covering pagination, malformed input, authorization, and retry semantics without copying test code.","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Today: projects/overture/ml/pipeline/features.py 里的 OvertureFlintTimelineStore 最近在 Room 流程中出现间歇性问题。 请给出阶段、兼容层、指标、rollback 和 ownership，先不要修改代码。\n\n约束：\n- 继续使用 Room\n- 保持兼容性和取消语义\n- 改动只限于 OvertureFlintTimelineStore","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"zh"}
{"prompt":"Collapse the OvertureCraneWorkspaceService wrappers","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Design the OvertureJuniperCLIService rollback","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Polish the OverturePineMetricsService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"OvertureSableParserCoordinator: handle the lingering thing","purpose":"backendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Before touching projects/overture/Sources/CLI/Commands/Doctor.swift, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"This should remain a deliberately small patch: OvertureAcornWidgetStore has one known configuration mistake in projects/overture/config/staging.toml, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing Swift 6 deployment\n- keep the work scoped to OvertureAcornWidgetStore and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"Trace OvertureOpalRouterStore's memory growth","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Context: Incident timeline — INC-55143\n\n08:02 deploy OvertureFlintTimelineFlow 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 OvertureFlintTimelineFlow rollout strategy: phases, dual-operation window, validation, ownership, removal criteria, and explicit stop conditions.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Background: Incident timeline — INC-55121\n\n08:02 deploy OvertureFernSnapshotFlow 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\nBearbeite auf Basis dieses Kontexts die beschriebene Aufgabe; API, Kompatibilität und Rollback müssen erhalten bleiben. Turn the material above into a concise OvertureFernSnapshotFlow 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":"Question: Incident timeline — INC-55157\n\n08:02 deploy OvertureMarbleTokenCoordinator 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 OvertureMarbleTokenCoordinator 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":"Assess the OvertureCoralUploadService diff","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'OvertureNovaPickerFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[OvertureNovaPickerFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/overture/db/migrations/20260730_events.sql:144: error: -[OvertureNovaPickerFlowTests 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 '-[OvertureNovaPickerFlowTests 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 OvertureNovaPickerFlow'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":"Does OvertureLumenChartStore 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.6,"slice":"core","lang":"en"}
{"prompt":"Summarize the OvertureCopperBridgeService changes","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Does OvertureCopperBridgeStore preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Any races in OvertureCloudReconcilerStore?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"Test Suite 'OvertureEmberRelayCoordinatorTests' started at 2026-07-30 09:22:14.018\nTest Case '-[OvertureEmberRelayCoordinatorTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/overture/engine/render/atlas.cpp:144: error: -[OvertureEmberRelayCoordinatorTests 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 '-[OvertureEmberRelayCoordinatorTests 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\nBring OvertureEmberRelayCoordinator's sheet to release quality across phone and tablet layouts; preserve its data flow while correcting selection, keyboard, VoiceOver, and animation states.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Draft OvertureCloudReconcilerService's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"What sequence would let OvertureBirchMigratorStore adopt Swift 6 with dual reads but no dual writes? Include data validation, canary scope, and the decision that ends compatibility mode. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"OvertureFrostPanelCoordinator: diagnose, then document","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"Clarify OverturePineMetricsStore's retry docs","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"OvertureFernSnapshotCoordinator: document, then assess","purpose":"writing","secondary":"review","mixed":true,"difficulty":0.4,"slice":"mixed","lang":"en"}
{"prompt":"Before touching projects/overture/crates/index/src/segment.rs, propose how to retire its legacy format while old clients remain active for ninety days and operators retain a reversible escape hatch. Stop at the restructuring strategy rather than editing files.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.9,"slice":"core","lang":"en"}
{"prompt":"Compare OvertureCraneWorkspaceStore's two adapters","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Polish the OvertureWrenExportService toolbar","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"projects/overture/infra/modules/edge/main.tf now contains OverturePrismCacheStore's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"# projects/overture/ml/pipeline/features.py\n[worker.overtureopalrouterflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.overtureopalrouterflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.overtureopalrouterflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.OvertureOpalRouterFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-55133\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/overture/ml/pipeline/features.py and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Observation: # projects/overture/packages/api/openapi.yaml\n[worker.overturesableparserflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.overturesableparserflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.overturesableparserflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.OvertureSableParserFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-55137\nThe upstream gateway minimum was raised to thirty seconds last month. Production was corrected in the same change, but the staging override and its focused assertion were missed. The service owner has confirmed this is a configuration-only correction: no retry counts, grace periods, pool sizes, production values, or dependency versions should move. A staging deploy is sufficient validation, and rollback is the previous config map.\n\nCom este contexto, trate a solicitação indicada preservando API, compatibilidade e rollback, com decisões e evidências claras. Align OvertureSableParserFlow'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":"Constraint: // projects/overture/config/staging.toml\nfinal class OvertureBirchMigratorFlowCoordinator {\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 OvertureBirchMigratorFlow 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":"# CI job 55114: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: FastAPI\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] OvertureBeaconStoreFlowIntegration.replays_after_timeout ... ok\n[test] OvertureBeaconStoreFlowIntegration.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\nAdd the bounded OvertureBeaconStoreFlow 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.9,"slice":"pasted-context","lang":"en"}
{"prompt":"One contained cleanup in projects/overture/workers/thumbnail/consumer.ex: remove the obsolete OvertureKiteSchedulerFlow import and let the existing formatter settle the blank line.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"Bring OvertureNimbusFormStore'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":"Request: projects/overture/src/sync/reconcile.ts now contains OvertureMapleQueueFlow's normalization branch three times. Consolidate it behind one private helper, keep call ordering identical, and avoid touching generated code. Please preserve behavior.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"OvertureOrbitSyncCoordinator is blocking the next release because lease renewal code copied across three workers. I need two concrete outcomes from a single pass: produce a consumer guide for OvertureOrbitSyncCoordinator, and give the existing implementation a read-only safety pass. Use the existing Room conventions in projects/overture/cmd/exporter/main.py; preserve cancellation and back-pressure semantics. 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":"writing","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Goal: // projects/overture/workers/thumbnail/consumer.ex\nfinal class OvertureCedarPolicyFlowCoordinator {\n private let store: EventStore\n private let clock: Clock\n private var pending: [Event.ID: Task<Void, Never>] = [:]\n\n func accept(_ event: Event) {\n pending[event.id]?.cancel()\n pending[event.id] = Task {\n let normalized = normalize(event)\n try? await store.persist(normalized)\n await MainActor.run {\n NotificationCenter.default.post(\n name: .eventDidPersist,\n object: event.id\n )\n }\n }\n }\n\n func stop() {\n pending.values.forEach { $0.cancel() }\n pending.removeAll()\n }\n}\n\n// A second copy lives in PreviewCoordinator.swift. It uses the same normalization\n// rules but calls store.persist before assigning the Task into `pending`.\n\nTests currently cover successful persistence and explicit stop. They do not cover replacement of an in-flight event with the same ID, cancellation thrown by the store, or whether the notification may arrive after stop returns. Public callers rely on accept being synchronous.\n\nConsolidate OvertureCedarPolicyFlow'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":"OverturePrismCacheCoordinator: give it a nicer flow","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"OvertureRavenSessionCoordinator: maybe tighten this up","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.4,"slice":"vague-eval","lang":"en"}
{"prompt":"Incident timeline — INC-55119\n\n08:02 deploy OvertureFrostPanelFlow 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 OvertureFrostPanelFlow, 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":"Bring OvertureBasilRunnerService'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":"Two deliverables are holding up OvertureIrisBatchCoordinator. First, find the unknown cause of timestamps rendered one day ahead near UTC midnight. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/overture/services/ledger/replay.go, which follows OpenTelemetry conventions and currently suffers from timestamps rendered one day ahead near UTC midnight. Preserve cancellation and back-pressure semantics.\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":"debugging","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"Symptom: # projects/overture/Sources/App/SessionStore.swift\n[worker.overturequartzplayerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.overturequartzplayerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.overturequartzplayerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.OvertureQuartzPlayerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-55118\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/overture/Sources/App/SessionStore.swift and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"Please resist widening this one: OvertureWrenExportStore works, but staging still carries a setting that production corrected last month. Align the one stale configuration entry with production, refresh only its focused snapshot, and leave retries, grace periods, dependencies, and neighboring comments untouched.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureWrenExportStore\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS monorepo, so keep ownership and handoff points understandable in a small review.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"# CI job 55154: integration-linux\nrunner: ubuntu-24.04 / amd64 / 8 cores\ntoolchain: FastAPI\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] OvertureMapleQueueCoordinatorIntegration.replays_after_timeout ... ok\n[test] OvertureMapleQueueCoordinatorIntegration.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\nDeliver the OvertureMapleQueueCoordinator 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.8,"slice":"pasted-context","lang":"en"}
{"prompt":"OvertureLedgerGateCoordinator: diagnose, then document","purpose":"debugging","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"This should remain a deliberately small patch: OvertureOrbitSyncService has one known configuration mistake in projects/overture/ml/pipeline/features.py, not an open-ended failure investigation. Correct the known literal and the test that intentionally mirrors it; the final diff should stay local enough for an on-call engineer to verify at a glance.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing Room deployment\n- keep the work scoped to OvertureOrbitSyncService and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"core","lang":"en"}
{"prompt":"PM is preparing the OvertureAtlasSearchStore rollout and needs prose that works for both application developers and the operators who will carry the pager. Turn the repository behavior into a compact reference with prerequisites, request and response examples, failure semantics, a rollback note, and links to the authoritative config keys.\n\nConstraints:\n- cover cancellation, retries, and rollback in the result\n- avoid unrelated changes outside OvertureAtlasSearchStore\n- preserve cancellation and back-pressure semantics\n\nSeveral teams work in this IoT fleet, Ruby, SolidJS 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":"diff --git a/projects/overture/infra/modules/edge/main.tf b/projects/overture/infra/modules/edge/main.tf\nindex 62d71aa..90f3c1e 100644\n--- a/projects/overture/infra/modules/edge/main.tf\n+++ b/projects/overture/infra/modules/edge/main.tf\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 OvertureRainfallDBFlow by responsibility and make cancellation ownership explicit. Characterize the current sequence before moving code and keep callers unchanged.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"pasted-context","lang":"en"}
{"prompt":"Headsup: projects/overture/cmd/exporter/main.py の OvertureFlintTimelineService で、Room の flow に断続的な問題が起きています。 現在の flow を読み、ownership、cancel、順序が安全か評価してください。分析だけで十分です。\n\n制約:\n- Room を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は OvertureFlintTimelineService のみ","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"boundary","lang":"ja"}
{"prompt":"Production says OvertureEchoRegistryService is healthy while users see stalled work, and the current telemetry does not reveal which ownership boundary lost progress. 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- touch generated artifacts only through their checked-in generator\n- preserve cancellation and back-pressure semantics\n- retain the current Swift 6 operational envelope\n\nThis repository spans IoT fleet, Ruby, SolidJS; use its existing conventions rather than importing a new abstraction.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Why does OvertureGarnetModalService's FastAPI worker stop making progress while its health endpoint remains green? Gather evidence from the scheduler and queue code and narrow the failure mode.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.5,"slice":"core","lang":"en"}
{"prompt":"UI ticket DES-55127: finish the compact OvertureHarborIndexFlow filter experience\n\nRoute: /catalog/search\nSource: projects/overture/config/staging.toml\nFramework: Swift 6\n\nCurrent QA notes\n- at 390 px the filter sheet is wider than the viewport by 16 px\n- returning from background selects segment four while the visible chip says three\n- keyboard focus falls behind the sheet after Apply\n- VoiceOver announces the internal value `sync_state_retriable`\n- the loading spinner never resolves into an offline action\n- dark appearance uses the light divider token\n- Reduce Motion still runs the spring transition\n- at accessibility XXXL the footer buttons overlap\n\nBrowser console during the transition:\n[ui] sheet.presented source=toolbar selected=3\n[ui] scene.inactive cachedSelection=3\n[ui] scene.active restoredSelection=4\n[ui] focus.restore target=filter-button result=detached\n[ui] network.status value=offline renderedState=loading\n\nAcceptance criteria from design\nThe phone layout should use an edge-to-edge sheet; tablet keeps the anchored panel. Applying filters returns focus to the opener and announces the result count. Empty, offline, retrying, and loaded states must be visually distinct. Use existing design tokens, support keyboard escape, preserve current data requests, and provide a no-animation path when Reduce Motion is enabled.\n\nFinish the visible OvertureHarborIndexFlow state described above: responsive layout, correct selection restoration, keyboard focus, accessible labels, dark mode, and reduced-motion behavior.","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Ticket OPS-55136: retire the legacy replay path for OverturePrismCacheFlow\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 OverturePrismCacheFlow 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":"OvertureCedarPolicyCoordinator needs a paired pass: change OvertureCedarPolicyCoordinator's known staging timeout from 15 to 30 seconds, plus capture the contract and rollback note for consumers. Use projects/overture/ui/settings/PrivacyPane.tsx as the source of truth, preserve the gRPC contract, and avoid unrelated cleanup.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.5,"slice":"mixed","lang":"en"}
{"prompt":"FYI: Does OvertureLedgerGateService preserve ordering?","purpose":"review","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Responsive layout for OvertureJuniperCLIStore","purpose":"frontendImpl","secondary":null,"mixed":false,"difficulty":0.5,"slice":"vague-eval","lang":"en"}
{"prompt":"OvertureSpruceDaemonCoordinator: ship a sensible version","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.3,"slice":"vague-eval","lang":"en"}
{"prompt":"Meanwhile: # projects/overture/engine/render/atlas.cpp\n[worker.overturecloudreconcilerflow]\nenabled = true\nrequest_timeout_seconds = 15\nshutdown_grace_seconds = 10\nmax_in_flight = 32\nretry_attempts = 4\nretry_base_milliseconds = 250\n\n[worker.overturecloudreconcilerflow.staging]\nrequest_timeout_seconds = 15\nemit_debug_spans = true\n\n[worker.overturecloudreconcilerflow.production]\nrequest_timeout_seconds = 30\nemit_debug_spans = false\n\nFailing assertion:\n ConfigTests.OvertureCloudReconcilerFlow.staging_timeout_matches_supported_gateway\n expected: Duration.seconds(30)\n actual: Duration.seconds(15)\n\nTicket note CFG-55130\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/overture/engine/render/atlas.cpp and its adjacent assertion. Avoid broader cleanup.","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"pasted-context","lang":"en"}
{"prompt":"2026-07-30T08:14:11.409Z level=info service=overturekiteschedulercoordinator pod=overturekiteschedulercoordinator-7cf8 request_id=55155 msg=\"lease acquired\" partition=12 epoch=884\n2026-07-30T08:14:11.417Z level=debug service=overturekiteschedulercoordinator request_id=55155 msg=\"batch loaded\" rows=250 cursor=01JZ7M\n2026-07-30T08:14:11.590Z level=warn service=overturekiteschedulercoordinator request_id=55155 msg=\"heartbeat delayed\" elapsed_ms=3012 deadline_ms=3000\n2026-07-30T08:14:11.593Z level=info service=overturekiteschedulercoordinator request_id=55155 msg=\"lease renewed\" partition=12 epoch=885\n2026-07-30T08:14:11.598Z level=error service=overturekiteschedulercoordinator request_id=55155 msg=\"commit rejected\" expected_epoch=884 actual_epoch=885\n2026-07-30T08:14:11.601Z level=info service=overturekiteschedulercoordinator request_id=55155 msg=\"retry scheduled\" attempt=1 delay_ms=0\n2026-07-30T08:14:11.617Z level=warn service=overturekiteschedulercoordinator request_id=55155 msg=\"duplicate key ignored\" event_id=ev_29af\n2026-07-30T08:14:11.620Z level=info service=overturekiteschedulercoordinator request_id=55155 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 OvertureKiteSchedulerCoordinator 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":"Locally: Test Suite 'OvertureAsterWebhookFlowTests' started at 2026-07-30 09:22:14.018\nTest Case '-[OvertureAsterWebhookFlowTests testRestoresSelectionAfterBackgrounding]' started.\nprojects/overture/app/src/main/SyncWorker.kt:144: error: -[OvertureAsterWebhookFlowTests 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 '-[OvertureAsterWebhookFlowTests testRestoresSelectionAfterBackgrounding]' failed (4.812 seconds).\n\nSimulator: iPhone 17 Pro, iOS 27.0, en_US, content size XXXL, Reduce Motion enabled. The screenshot looks correct. The mismatch is the internal selected-segment index after the scene becomes active; tapping Apply a second time makes it three again.\n\nÀ partir de ce contexte, traite la demande indiquée en préservant API, compatibilité et rollback, avec des décisions explicites. Find the source of this OvertureAsterWebhookFlow symptom by following task lifetime, cursor movement, durable writes, and cleanup. Propose code only after the evidence supports one cause.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"A previously stable test around OvertureNovaPickerService now fails one run in twenty. Determine whether ordering, locale, or leaked state is responsible.","purpose":"debugging","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"diff --git a/projects/overture/Sources/CLI/Commands/Doctor.swift b/projects/overture/Sources/CLI/Commands/Doctor.swift\nindex 62d71aa..90f3c1e 100644\n--- a/projects/overture/Sources/CLI/Commands/Doctor.swift\n+++ b/projects/overture/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\nRestructure OvertureSpruceDaemonFlow 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":"Two engineers disagree about whether OvertureGarnetModalStore's cache is authoritative. Walk the reads and writes in projects/overture/app/src/main/SyncWorker.kt and settle that question from the code.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"en"}
{"prompt":"Split projects/overture/cmd/exporter/main.py by responsibility, not file length: isolate parsing, validation, and persistence while leaving the exported surface and call sequence untouched.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.6,"slice":"core","lang":"en"}
{"prompt":"Extract OvertureAsterWebhookService's parsing loop","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Rename OvertureRainfallDBStore's staleLease state","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.3,"slice":"boundary","lang":"en"}
{"prompt":"I inherited OvertureWillowCodecService and need a careful read of projects/overture/services/ledger/replay.go before I can sign off on the next release. Assess authorization, concurrency, durability, and shutdown behavior against existing tests, highlighting any undocumented assumption that a caller could violate.\n\nConstraints:\n- preserve cancellation and back-pressure semantics\n- stay compatible with the existing OpenTelemetry deployment\n- keep the work scoped to OvertureWillowCodecService and its direct tests\n\nThe relevant code crosses IoT fleet, Ruby, SolidJS. Prefer evidence from the repository and make any assumption explicit.","purpose":"review","secondary":null,"mixed":false,"difficulty":0.8,"slice":"core","lang":"en"}
{"prompt":"Ticket OPS-55138: retire the legacy replay path for OvertureDeltaCanvasFlow\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 OvertureDeltaCanvasFlow 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":"Production: Ticket OPS-55142: retire the legacy replay path for OvertureRavenSessionFlow\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 OvertureRavenSessionFlow 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":"Staging: Two deliverables are holding up OvertureBeaconStoreCoordinator. First, separate OvertureBeaconStoreCoordinator's policy from transport without behavior changes. In the same workstream, give the existing implementation a read-only safety pass. The relevant starting point is projects/overture/src/sync/reconcile.ts, which follows FastAPI conventions and currently suffers from duplicate retries after a network handoff. Preserve cancellation and back-pressure semantics.\n\nPlease make the boundary between analysis and changes obvious, preserve tenant and wire compatibility, exercise cancellation plus retries, and leave unrelated generators alone. The handoff should include one measurable rollback signal and enough repository evidence for separate reviewers to verify each outcome.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.8,"slice":"mixed","lang":"en"}
{"prompt":"OvertureLumenChartCoordinator: the docs need something","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Remove OvertureAsterWebhookStore's stray comma","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.1,"slice":"core","lang":"en"}
{"prompt":"For OvertureAsterWebhookCoordinator, separate OvertureAsterWebhookCoordinator's policy from transport without behavior changes; once that is complete, give the existing implementation a read-only safety pass. Work from projects/overture/apps/console/routes/usage.svelte, stay with FastAPI, and preserve cancellation and back-pressure semantics. Keep the two outcomes separately reviewable.","purpose":"refactor","secondary":"review","mixed":true,"difficulty":0.7,"slice":"mixed","lang":"en"}
{"prompt":"Is there a cleaner way to separate OvertureCinderAuthService's transport, persistence, and retry policy without changing its API or timing behavior? Go ahead and make that structural change.","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"core","lang":"en"}
{"prompt":"OvertureDeltaCanvasCoordinator: could this be clearer","purpose":"review","secondary":null,"mixed":false,"difficulty":0.2,"slice":"vague-eval","lang":"en"}
{"prompt":"Atlas: projects/overture/services/ledger/replay.go の OvertureWillowCodecFlow で、OpenTelemetry の flow に断続的な問題が起きています。 責務を分離して重複をなくし、API、wire value、順序、観測可能な動作は変えないでください。\n\n制約:\n- OpenTelemetry を継続利用\n- 互換性と cancel の意味を維持\n- 変更範囲は OvertureWillowCodecFlow のみ","purpose":"refactor","secondary":null,"mixed":false,"difficulty":0.7,"slice":"boundary","lang":"ja"}
{"prompt":"PM needs a concise migration note for OvertureRavenSessionStore, 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":"Beacon: Ticket OPS-55144: retire the legacy replay path for OvertureMicaProfileFlow\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 OvertureMicaProfileFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Incident timeline — INC-55141\n\n08:02 deploy OvertureNimbusFormFlow 6.18.0 begins in eu-west\n08:06 write latency rises from 22 ms to 410 ms; error rate remains below 0.2%\n08:08 autoscaler adds three workers; queue lag continues rising\n08:11 on-call disables feature flag `parallel_commit_v2`\n08:13 latency returns to 31 ms, but duplicate-event warnings increase\n08:19 traffic moved to the previous worker pool\n08:27 queue lag clears; no customer data loss observed\n\nWhat changed\nThe release moved metrics emission into the same Promise.all as the durable write and added NFC normalization to event payloads. Database CPU peaked at 64%, Redis stayed normal, and the downstream consumer reported 183 duplicate keys that its uniqueness constraint ignored.\n\nConstraints from incident command\n- no emergency schema change\n- preserve tenant ordering\n- canary must include a forced consumer rebalance\n- rollback decision must use two independent signals\n- ownership between storage and ingestion teams must be explicit\n\nThe next regular release window is in six days.\n\nMap a safe route from the current OvertureNimbusFormFlow behavior to the desired one, comparing two approaches and naming telemetry, failure drills, and rollback responsibility.","purpose":"planning","secondary":null,"mixed":false,"difficulty":0.8,"slice":"pasted-context","lang":"en"}
{"prompt":"Documente o contrato de OvertureHarborIndexService","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.4,"slice":"core","lang":"pt"}
{"prompt":"Fresh release brief for OvertureCoralUploadCoordinator:\n- primary outcome: change OvertureCoralUploadCoordinator'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/overture/workers/thumbnail/consumer.ex\n- platform constraint: gRPC\n- known complication: a query plan that changes after statistics refresh\n\nBoth results are required, but they should remain independently reviewable. Preserve cancellation and back-pressure semantics; retain serialization and authorization boundaries; cover cancellation, idempotent retries, and rollback; and avoid drive-by cleanup. Use the code as the source of truth, call out assumptions, and state how an on-call engineer can tell that either part is unsafe to ship.","purpose":"quickFix","secondary":"writing","mixed":true,"difficulty":0.6,"slice":"mixed","lang":"en"}
{"prompt":"Draft OvertureSlateEditorStore's upgrade note","purpose":"writing","secondary":null,"mixed":false,"difficulty":0.3,"slice":"core","lang":"en"}
{"prompt":"Zentriere das OvertureFrostPanelStore-Modal","purpose":"quickFix","secondary":null,"mixed":false,"difficulty":0.2,"slice":"boundary","lang":"de"}