fix(turdus): migrate email/task stores from deprecated /observations to /store

[markmhendrickson]

Live production bug

Turdus is failing right now with 404 Not Found on POST /observations:

ERROR turdus Failed to create task for email: Client error '404 Not Found' for url 'http://localhost:9180/observations'
ERROR turdus Failed to store email entity: Client error '404 Not Found' for url 'http://localhost:9180/observations'

The /observations endpoint was removed from Neotoma, so every inbound email Turdus processes fails to store — no email_message entity, no derived task. Silent data loss on the inbound-mail path.

Fix

Migrate _store_email_entity and _create_task_for_email to POST /store, wrapping the entity in an entities: [...] array with an idempotency_key (turdus-email-<msgid> / turdus-task-<msgid>), and read the entity id back from entities[0].entity_id. Payload shape matches the known-good caller in lib/daemon_runtime/gating.py.

Provenance

Pre-existing (present on main), independent of the approval-loop PR #189 — surfaced when Turdus was restarted to deploy the approval loop. Kept as its own PR for clean history.

Verification

turdus.py parses; payload shape verified against gating.py. Will confirm live (no more 404s, entities created) after merge + restart.

🤖 Generated with Claude Code

[ateles-agent]

🤖 Apis — Ateles swarm, swarm dispatcher

⚠️ Pipeline bypass — this PR touches product code but has no parent issue, so it skipped the gated pipeline (issue triage → pm/arch sign-off → Cicada implementation).

The review panel still runs and merge stays operator-gated, so nothing is blocked. To restore traceability, file the issue and add a Closes #N line to this PR description, then re-run the pipeline. Otherwise the gates are being back-filled after the fact rather than earned up front.

[github-actions]

Loxia Review 🪶

Verdict: APPROVE

Summary

Migrates _store_email_entity and _create_task_for_email from the removed /observations endpoint to /store, adopting the entities-array + idempotency_key shape used by the known-good write_checkpoint_brief caller. Adds a thorough regression test suite covering endpoint URL, payload shape, task↔email linking, response-parsing contract, and fail-open behavior.

Findings

• 🔴 Secrets: none detected — the only token is the literal "test-token" fixture value passed to monkeypatch.setenv; no real credentials in the diff.
• 🟡 Scope: focused — both files serve the single /observations→/store migration; the test file is the regression counterpart to the fix.
• 🟢 gitleaks: not needed — the new test file references the NEOTOMA_BEARER_TOKEN name only, with an obviously-fake "test-token" value; no high-entropy secret for gitleaks to flag, no allowlist change required.
• 🟢 Linting: no issues visible — imports are all used, formatting matches the surrounding style, async fixtures are well-formed.
• 🟢 Pattern: follows conventions — uses httpx (not requests), aligns the payload/response contract with the repo's only other known-good /store caller (gating.py::write_checkpoint_brief). Minor: the response parser's primary branch data.get("entity_id") (top-level) has no precedent — write_checkpoint_brief reads entities[0].entity_id exclusively. The or fallback makes this harmless and the test suite explicitly locks in both branches, so no change required; consider dropping the unprecedented primary branch in a future cleanup if the /store contract is confirmed to never return a top-level entity_id.
• 🟢 Docs: no doc updates needed — no new public daemon/skill surface; turdus already exists and CLAUDE.md needs no change.

---

Loxia automated review · commit 3dccc54

[ateles-agent]

🤖 Lanius — Ateles swarm, PR gate inheritance
COMMENT

Triage & Gate-Status Board (updated — synchronize event, commit 3dccc54)

Parent issue lookup: no closes #N/fixes #N in body/title/commits; no GitHub issue exists for this PR (GitHub issue-number lookup on #190 resolves to this PR itself, confirming no separate issue was ever filed). Same result as all prior passes.

Legacy backfill (unchanged from prior triage): this is a live-production-bug hotfix with no independent parent issue, so pm/arch remain not_applicable. ux is not_required (bug fast-path). impl is signed_off (PR open, CI green).

Gate status

Gate	State	Owner
pm	not_applicable	— (no parent issue)
ux	not_required	— (bug fast-path)
arch	not_applicable	— (no parent issue)
impl	signed_off	Gryllus
pr_review	pending re-aggregation (see below)	Vanellus
qa	pending	Phoenicurus
legal	not_required	—

Pre-impl gate inheritance: CLEAR

No pre-impl gate (pm/ux/arch) is open — PR gate inheritance does not block this PR.

pr_review status note (not a gate-inheritance issue)

Vanellus's last aggregation (REQUEST_CHANGES) was keyed to commit b446a85 and cited two blocking qa findings: no regression test proving the outbound POST targets /store, and no contract test pinning the entity_id vs entities[0].entity_id response-parsing branch. Commit 3dccc54 ("test(turdus): add coverage for /store migration + entity_id parsing") is newer than b446a85 and adds execution/daemons/turdus/test_turdus_store_migration.py, which appears to target exactly those two findings. CI (Loxia PR review, gitleaks) is green on current HEAD. I haven't re-run the qa/pr_review lenses myself — that verdict is Vanellus's and Phoenicurus's to re-issue against 3dccc54, not mine to presume.

Owner / next phase: Vanellus (re-aggregate pr_review + qa against 3dccc54) → operator merge gate.

Labels: none applied by Lanius on this pass (issue entity already exists from prior triage).

Note: Neotoma MCP session was unavailable during this pass (Service Unavailable: MCP session is unknown on this API instance — server-side sticky-session/replica issue, not a caller error). Gate-status table above reflects the last known-good Neotoma read (issue ent_7464cb8fbbaf61ab9aabc0bd) plus GitHub-observable state; no new Neotoma writes were made this pass. Will reconcile once the session recovers.

📎 Neotoma: issue ent_7464cb8fbbaf61ab9aabc0bd

GATE_INHERITANCE: clear

[ateles-agent]

review:pm
🤖 Pavo — Ateles swarm, pm lens panelist

Reviewed through the pm lens: scope match to stated intent, no unrequested scope creep, user-visible behavior parity with the described bug. No parent issue exists for this PR — Lanius already marked the pm gate not_applicable and Apis flagged the pipeline bypass; I'm reviewing against the PR description as the de facto spec since no pm gate was pre-registered.

Scope assessment: Change is tightly bounded to the two write paths named in the PR description (_store_email_entity, _create_task_for_email) in execution/daemons/turdus/turdus.py. It migrates only the endpoint (/observations → /store) and payload shape (wrapping in entities: [...] + idempotency_key), matching the known-good caller shape in lib/daemon_runtime/gating.py. No unrelated refactors, no drive-by changes. Matches stated intent exactly — no scope creep.

Response parsing check: confirmed the entity_id = data.get("entity_id") or (data.get("entities", [{}])[0].get("entity_id")) fallback (lines ~391 and ~482) already handles the new /store response shape correctly — this logic was pre-existing/defensive, not a gap, so the PR description's claim about entity-id extraction holds.

[NON-BLOCKING] verification-gap: fix is asserted, not behaviorally verified pre-merge
The PR body states: "Will confirm live (no more 404s, entities created) after merge + restart." This is a live-production data-loss bug (every inbound email silently fails to store), so ship-then-verify is a reasonable operational tradeoff for a hotfix — but the acceptance criterion "entities actually get created" is unverified at merge time. Per standing policy fixed_means_behavior_verified_not_contract_accepted (ent_db0b7855d47012084477fb00), "fixed" should mean the reported effect was observed corrected, not that the payload shape merely matches a known-good caller. Recommend a quick staging smoke test pre-merge, or an explicit follow-up comment confirming post-restart entity creation succeeded.

[NON-BLOCKING] process: no parent issue filed for a production bug fix
Per Apis's pipeline-bypass notice on this PR, product-code changes without a parent issue skip pm/arch/ux sign-off. For a one-file, mechanically-scoped hotfix this is low-risk and not blocking, but recommend filing a retroactive issue (as Apis suggested) so this fix and its live-production context (when the 404s started, how discovered) are captured in Neotoma rather than living only in PR history.

Cross-surface note: no other MCP/CLI/REST caller duplicates these two Turdus write paths, so the cross-surface parity policy (ent_2ad0677fe23c0c1878ae43e8) doesn't apply here.

No blocking findings from the pm lens.

[ateles-agent]

review:qa
🤖 Phoenicurus — Ateles swarm, qa lens panelist
REQUEST_CHANGES

Scope: test coverage adequacy only (regression test for the fixed bug, edge cases for new branches, contract coverage for the /store payload shape). Correctness/security is the GHA baseline's job, not mine.

• Regression test for the fixed 404 bug
• Edge-case coverage for new branches
• Contract test for the new endpoint/payload shape

[BLOCKING] regression-test-missing: no test locks in the /observations → /store migration that caused the live 404 outage
This PR fixes a live production data-loss bug (silent failure to store email_message and task entities on every inbound email) but ships zero test changes. execution/daemons/turdus/turdus.py has a sibling test file, execution/daemons/turdus/test_turdus_approval.py, that already establishes the pattern for testing this exact daemon — pure-function tests plus monkeypatch-guarded async-handler tests with stubbed I/O. Neither _store_email_entity nor _create_task_for_email has any test today, before or after this PR. Nothing in CI would catch a regression back to /observations, a typo in the new entities: [...] wrapper, or a dropped idempotency_key. Given this is precisely the kind of silent-failure bug the PR is fixing, the fix itself should be the thing that makes a regression like it impossible to reintroduce unnoticed.
Suggested minimal fixture: respx-style or monkeypatched httpx.AsyncClient.post capturing the outgoing request, asserting (a) URL is {NEOTOMA_BASE_URL}/store (not /observations), (b) payload shape is {"entities": [{"entity_type": ..., "canonical_name": ..., "snapshot": {...}}], "idempotency_key": "turdus-email-<id>"} for _store_email_entity and "turdus-task-<id>" for _create_task_for_email, and (c) entity_id/task_id is correctly read back from a stub response shaped like the real /store envelope ({"entities": [{"entity_id": "..."}]}).

[BLOCKING] contract-drift-unverified: response-parsing fallback (data.get("entity_id") or data.get("entities", [{}])[0].get("entity_id")) is untested against the real /store response envelope, and diverges from the PR's own stated source of truth
The PR description says payload shape was "verified against gating.py" (lib/daemon_runtime/gating.py:349-359). I pulled that file: gating.py parses the response as data.get("entities") or [] → ents[0].get("entity_id") if ents else None — it does not check a top-level entity_id first. This PR's parsing adds an untested data.get("entity_id") first branch that has no known-good precedent anywhere in the repo. If /store never returns a top-level entity_id (which gating.py's pattern implies), that branch is silently dead code; if /store sometimes does, there's no test asserting the daemon picks the right one. A one-line unit test stubbing the response as {"entities": [{"entity_id": "abc"}]} (no top-level entity_id) would pin this down and catch drift the next time the /store contract changes.

[NON-BLOCKING] contract-test-missing: the /create_relationship call in _create_task_for_email (turdus.py:490-498) is adjacent to this migration, untouched by it, and has zero precedent or test coverage in the repo
gating.py's known-good pattern creates the task↔checkpoint relationship inline inside the same /store call via a relationships block with source_index/target_entity_id (gating.py:340-347), not as a second bare POST to /create_relationship. Grepping the full repo tree, turdus.py:497 is the only place that POSTs to a standalone /create_relationship path. It's plausible this endpoint doesn't exist post-migration the same way /observations didn't, and this code path would fail exactly as silently as the bug this PR fixes (exception is caught and logged, task creation still "succeeds"). Not blocking this PR since it's out of the stated diff, but flagging so it doesn't become the next silent-data-loss incident — worth a fast follow-up: either a contract test hitting /create_relationship, or migrating this call to the inline relationships form used by gating.py for consistency.

[NON-BLOCKING] edge-case-coverage: no test for the NEOTOMA_BEARER_TOKEN unset / DRY_RUN branches in the two migrated functions
Both _store_email_entity and _create_task_for_email early-return on missing token or DRY_RUN=True (turdus.py:347-349, 351-355, 411-412, 452-457) — these guard against accidental writes in dev/CI. test_turdus_approval.py shows the existing convention for exercising these kinds of guards via monkeypatch. Cheap to add alongside the regression test above; would also close coverage on the "no NEOTOMA_BEARER_TOKEN" path, which is the exact silent-no-op state that made the original 404 bug hard to notice for as long as it apparently went unnoticed.

Standing rule cited: Phoenicurus QA gate criteria (this agent's operating charter) — "a functional change is evaluated as if an agent is the consumer first" and "for any functional change: identify the agent-facing surface, enumerate cases, author the eval, commit it in the PR." This PR is squarely a functional change (fixes silent production data loss on an agent-facing write path) with no eval/test artifact attached, so per that gate criteria QA sign-off cannot be granted as-is.

[ateles-agent]

🤖 Vanellus — Ateles swarm, PR steward
REQUEST_CHANGES

Aggregated Review Verdict (PR steward)

PR: #190 — fix(turdus): migrate email/task stores from deprecated /observations to /store
Parent issue: none found (flagged below as a non-blocking gap)

Per-lens roll-up

• pm — comment — no blocking findings. Scope tightly matched to stated hotfix intent, no creep, response parsing already correct for the new /store shape.
• qa — comment — REQUEST_CHANGES, 2 blocking findings.

Blocking (from qa lens)

• [BLOCKING] No regression test for the /observations → /store migration despite this being a live production data-loss fix. Sibling test_turdus_approval.py already establishes the daemon's test pattern (monkeypatched httpx + async handler tests); neither migrated function (_store_email_entity, _create_task_for_email) has coverage.
• [BLOCKING] The response-parsing fallback (top-level entity_id check) has no precedent in gating.py (the PR's own cited "known-good" source) and isn't pinned by a test — real contract-drift risk.

This also trips the standing merge-readiness policy for this role: a "fixed" claim for a bug requires a test asserting the observed effect, not just contract/payload-shape acceptance (fixed_means_behavior_verified_not_contract_accepted). The pm lens independently flagged the same gap as a non-blocking note; qa's finding elevates it to blocking given this is a production data-loss fix.

Non-blocking

• [NON-BLOCKING] (qa) _create_task_for_email's call to a bare /create_relationship endpoint has no precedent anywhere in the repo (gating.py does this inline via /store's relationships block) — possible next silent-failure bug.
• [NON-BLOCKING] (qa) No coverage for NEOTOMA_BEARER_TOKEN-unset / DRY_RUN guard branches.
• [NON-BLOCKING] (pm) Fix verified only by payload-shape inspection, not an observed successful store pre-merge — acceptable tradeoff for a live hotfix, but worth a post-restart confirmation.
• [NON-BLOCKING] (pm) No parent issue exists, so this PR bypassed pm/arch/ux gate inheritance per Apis's own flag — recommend filing a retroactive issue for traceability.

Gate action

pr_review gate → changes_requested. Routing back to Gryllus to:

1. Add regression tests for _store_email_entity and _create_task_for_email covering the /store migration and the entity_id fallback parsing path, following the test_turdus_approval.py pattern.
2. Confirm (or justify) the /create_relationship call pattern against the gating.py precedent.

Merge recommendation

Not mergeable as-is — 2 blocking findings outstanding. No merge action taken (operator-gated by standing policy regardless).

Verdict: REQUEST_CHANGES

[markmhendrickson]

Added commit 8e34674 to this branch: a self-notification guard that fixes a runaway loop discovered while auditing swarm-generated email.

The loop: Turdus delivers its digests to the operator inbox via the ATELES_SWARM_EMAIL +swarm Gmail alias — same inbox, unread. The digest subject ([Ateles] [turdus] N invoice(s) → urgent task(s) …) matched _is_invoice(), so each poll re-triaged Turdus's own notification and fired another. Result: 148 self-sent digests in ~14h on 2026-07-07, 173 unread [Ateles] emails piled up as triage fuel.

The /observations→/store migration in this PR was also not live: the running daemon had loaded the file ~1 min before that commit landed and was never restarted, so it 404'd on every store (zero email/task entities created) — which is what accidentally throttled the loop.

This commit: _is_self_notification() (swarm From-address, or [Ateles] subject-prefix fallback), skipped in poll_once before classification. +4 regression tests (PII-free synthetic senders), all green with the existing 15.

Operational remediation already applied on the host: restarted the daemon onto the fixed code (/store now 200, self-notifications SELF-SKIPped, 0 digests emitted post-restart), reset the .turdus_state.json cursor, and archived + marked-read all 179 [Ateles] self-notifications out of the inbox (retained in Sent/All Mail).

[ateles-agent]

review:pm
🤖 Pavo — Ateles swarm, pm lens panelist

Re-reviewing through the pm lens now that commit 8e34674 (self-notification guard) has been added on top of my earlier pass (which covered only the /observations→/store migration).

Scope assessment — updated:

The PR title and body still describe only the /store migration ("migrate email/task stores from deprecated /observations to /store"). Commit 8e34674 adds a second, unrelated fix — a _is_self_notification guard breaking a runaway invoice self-notification loop — that is not reflected in the PR title or description at all. Taken in isolation this would be scope creep by my standing criteria (unrequested addition beyond the stated intent). Here it is mitigated by two facts: (1) the operator (the principal, not an implementer agent) pushed the commit directly and posted an explicit rationale comment describing discovery, root cause, and live remediation already applied; (2) the fix is well-isolated (new function + guard clause + dedicated test file, zero overlap with the /store migration code paths). So I'm not flagging this as scope creep in the "agent went off-script" sense the pm lens exists to catch — but the PR's own title/description is now stale relative to its contents, which matters for anyone reading history later.

User-visible behavior parity: Both fixes match their respective described bugs. The /store migration matches the 404-on-every-email description. The self-notification guard's behavior (skip swarm-authored digests before classification) matches the operator's description of the loop and is confirmed operationally applied (daemon restarted, 0 digests post-restart per the operator's comment).

[NON-BLOCKING] process: PR title/description does not reflect actual scope
The PR now bundles two independent fixes (store-endpoint migration + self-notification loop guard) under a title naming only one. Neither has a parent issue (confirmed again by Lanius's gate board after the second commit). Recommend either retitling the PR to reflect both fixes, or — preferred, since the PR body itself says the store-migration fix was "kept as its own PR for clean history" — splitting the self-notification guard into its own PR/issue so the "clean history" rationale actually holds. This is not blocking merge, but the stated intent behind keeping these separate has already been undercut by bundling a second unrelated fix in here.

[NON-BLOCKING] process: still no parent issue for either fix (repeat of prior finding)
Both the original /store migration and now the self-notification loop are live-production bug fixes with no Neotoma issue entity or GitHub issue backing them (Lanius confirms pm/arch remain not_applicable for lack of a parent issue). Recommend filing retroactive issues for both — the operator's own rationale comment for commit 8e34674 contains exactly the incident detail (148 self-fires in ~14h, discovery context, remediation steps) that should live in a traceable issue rather than only in PR comment history.

No blocking findings from the pm lens. The outstanding blocker on this PR remains qa's (Phoenicurus/Vanellus) requirement for regression/contract tests on the /store migration — unaffected by my re-review.

[ateles-agent]

review:qa
🤖 Phoenicurus — Ateles swarm, qa lens panelist
REQUEST_CHANGES

Scope: test coverage adequacy only (regression test for the fixed bug, edge cases for new branches, contract tests for new endpoints). Correctness/security is covered by the baseline GHA lens.

[BLOCKING] regression-coverage: the headline fix (/observations → /store migration in _store_email_entity / _create_task_for_email) ships with zero tests

• This is the actual production bug named in the PR title and description (404s causing silent data loss on the inbound-mail path), yet execution/daemons/turdus/turdus.py diff for _store_email_entity (~L354-410) and _create_task_for_email (~L467-515) has no corresponding test. The only new test file, test_turdus_self_guard.py, exercises _is_self_notification — a different bug (the self-notification loop from the second commit) — not the /store migration this PR is titled after.
• A regression test guarding against the 404 recurring (e.g. asserting the URL posted is {NEOTOMA_BASE_URL}/store, not /observations) is exactly the kind of test that would have caught this bug before it reached production, and prevents a silent re-regression if someone reverts or refactors the URL construction later.
• The repo already has the mocking pattern needed for this: lib/daemon_runtime/test_task_lifecycle.py::_capture does monkeypatch.setattr(tl, "NEOTOMA_BEARER_TOKEN", "test-token") + monkeypatch.setattr(tl.httpx, "post", fake_post) to capture and assert on the outgoing payload/URL against a fake httpx response. turdus.py's _store_email_entity/_create_task_for_email do a local import httpx inside the function body (not a module-level httpx.AsyncClient — note they use httpx.AsyncClient, async, so the mock needs an async-compatible client stub, but the shape is directly adaptable). No excuse of "no existing pattern to follow" applies — the pattern is in-repo, one directory over.

[BLOCKING] contract-test: new /store payload shape (entities: [...] + idempotency_key) and response parsing (entities[0].entity_id) are asserted only by eyeballing gating.py, never executed against a mocked response

• PR description says: "Payload shape matches the known-good caller in lib/daemon_runtime/gating.py" and "Verification: turdus.py parses; payload shape verified against gating.py." That is a read-the-code comparison, not a test run — there is no fixture proving the response shape turdus expects (data.get("entity_id") or data.get("entities", [{}])[0].get("entity_id")) actually matches what POST /store returns.
• gating.py::write_checkpoint_brief (the "known-good caller") parses the response as data.get("entities") or [] → ents[0].get("entity_id") — it does NOT try a top-level data.get("entity_id") first. Turdus's parsing tries data.get("entity_id") before falling back to entities[0].get("entity_id"). If the real /store response never has a top-level entity_id key (plausible, since the one confirmed-good caller doesn't reference it), the primary branch is untested dead code and only the fallback path is ever live — this asymmetry should be pinned down by a contract test using the actual response shape, not inferred by comparison.
• A same-shape assertion test (construct a canned /store-style response {"entities": [{"entity_id": "ent_123"}]} and confirm the daemon extracts ent_123 via whichever branch is truly live) closes this gap and would have caught a shape mismatch before the "will confirm live" step in the PR description, which currently defers all verification of this fix to post-merge production observation.

[NON-BLOCKING] edge-case: no test for the /store failure path (non-200, timeout, malformed JSON) on either migrated call

• Both _store_email_entity and _create_task_for_email wrap the post in try/except and log-and-return-None/return on Exception. Given this PR exists because a silent-failure mode already caused production data loss once, a test asserting the except branch degrades gracefully (doesn't raise, doesn't crash poll_once) would harden against the next silent-failure variant (e.g. Neotoma returns 500, or the response body is missing entities entirely instead of returning []).

[NON-BLOCKING] edge-case: _create_task_for_email's relationship-link call (POST /create_relationship, ~L487-495) is unexercised

• This runs conditionally when both email_entity_id and task_id are truthy — a case worth at least one assertion (task→email REFERS_TO link fires with the correct source_entity_id/target_entity_id) given it's new code path adjacent to the migration, not just a passthrough.

Non-blocking observations aside, the self-notification guard tests in test_turdus_self_guard.py (self-address match, subject-prefix fallback, real-invoice negative, actionable-mail negative) are well-targeted and appropriately named — that part of the diff meets the bar. The gap is specifically that the PR's own stated purpose (the /store migration fixing live 404s) has no regression or contract coverage riding along with it.

[ateles-agent]

🤖 Vanellus — Ateles swarm, PR steward
REQUEST_CHANGES

Aggregated Review Verdict (PR steward) — PR #190

Parent issue: none (legacy artifact — no parent GitHub issue exists for this PR; gates were retroactively backfilled by Lanius: pm/arch waived, impl signed_off).

Per-lens roll-up

pm (Pavo) — no blocking findings.

• /store migration matches stated bug fix, no scope-creep concern from the migration itself
• [NON-BLOCKING] process: PR title/description now understates scope after operator's follow-up commit 8e34674 (self-notification-loop guard) was added without updating the PR title/body
• [NON-BLOCKING] process: no parent issue exists for either bundled fix; recommend retroactive issue(s)

qa (Phoenicurus) — REQUEST_CHANGES, 2 blocking findings.

• [BLOCKING] regression-coverage: the headline fix (/observations → /store migration in _store_email_entity / _create_task_for_email) ships with zero tests. The only new test file (test_turdus_self_guard.py) covers the unrelated self-notification guard, not the migration this PR is titled after. An in-repo mocking pattern already exists (lib/daemon_runtime/test_task_lifecycle.py::_capture) and is directly adaptable.
• [BLOCKING] contract-test: the new /store payload/response shape is verified only by eyeballing gating.py, never executed against a mocked response. Turdus's response parsing (data.get("entity_id") before falling back to entities[0].get("entity_id")) diverges from the one confirmed-good caller (gating.py, which never checks a top-level entity_id) — this asymmetry is untested and the primary branch may be dead code.
• [NON-BLOCKING] edge-case: no test for /store failure path (non-200/timeout/malformed JSON) on either migrated call — notable given this PR exists because a silent-failure mode already caused production data loss.
• [NON-BLOCKING] edge-case: _create_task_for_email's /create_relationship call is unexercised.

Blocking vs non-blocking

Blocking (2) — both from qa, both target the PR's own stated purpose (the /store migration), not the bundled self-notification fix:

1. No regression test proving the fixed URL (/store, not /observations).
2. No contract test proving the response-parsing branch that's actually live matches real /store response shape.

Non-blocking (4) — 2 process notes from pm (retitle/scope clarity, retroactive issue filing), 2 edge-case hardening asks from qa (failure-path test, relationship-call test).

Merge recommendation

Do not merge. Route back to Gryllus to add:

• a regression test asserting the outbound POST targets /store (not /observations) for both _store_email_entity and _create_task_for_email, and
• a contract test pinning the response-parsing branch (entity_id vs entities[0].entity_id) against a canned /store-shaped response.

Once both land, comment @claude review to get a fresh head-SHA-matched verdict, then re-run aggregation.

Verdict

REQUEST_CHANGES

pr_review gate on the parent issue entity is set to changes_requested; ownership remains with Gryllus pending the above.

📎 Neotoma: issue

[ateles-agent]

🤖 Apis — Ateles swarm, swarm dispatcher

🔁 Auto-fix round 1 of 2: routing the panel's blocking findings back to the review agents for guidance, then to the implementer. A new push re-runs the panel.

[ateles-agent]

🤖 Phoenicurus — Ateles swarm, qa reviewer
REQUEST_CHANGES

Fix guidance for the two blocking QA findings. Both confirmed against the actual diff (execution/daemons/turdus/turdus.py) — not speculative.

Finding 1 — [regression-coverage] /store migration itself has zero tests

What's missing: _store_email_entity (turdus.py:350-409) and _create_task_for_email (turdus.py:412-~510) are the functions the PR title and description are about, but the only new test file — test_turdus_self_guard.py — covers _is_self_notification, a different bug from the second commit. The headline fix ships unverified.

What to add: a new test file, e.g. execution/daemons/turdus/test_turdus_store_migration.py, with async tests that:

1. Mock httpx.AsyncClient and assert the POST goes to f"{NEOTOMA_BASE_URL}/store", not /observations. This is the literal regression guard — it's what would have caught the 404 before it shipped.
2. Assert the outgoing JSON body shape: top-level entities: [...] (not the old flat entity_type/canonical_name/snapshot shape) and idempotency_key present with the expected value (turdus-email-{msg_id} / turdus-task-{msg_id}).
3. Cover both _store_email_entity and _create_task_for_email — they're separate functions with separate payload construction (turdus.py:369-389 and turdus.py:471-480), a test on one does not cover the other.

Why the existing pattern doesn't transfer as-is: lib/daemon_runtime/test_task_lifecycle.py::_capture (the in-repo httpx-mocking pattern) monkeypatches tl.httpx.post — a sync call, because task_lifecycle.py uses module-level httpx.post. turdus.py does something different: httpx is imported locally inside each function body (turdus.py:356, turdus.py — check the equivalent line in _create_task_for_email), and it uses httpx.AsyncClient(...) as an async context manager (turdus.py:392, turdus.py:483), not a bare httpx.post. Patching tl.httpx.post won't touch this code path at all.

Concrete adaptation: since httpx is imported locally (import httpx inside the function, not at module scope), monkeypatch.setattr(turdus.httpx, "post", ...) won't work either — there's no module-level turdus.httpx attribute to patch until the function runs. Recommend either (a) monkeypatch.setattr("httpx.AsyncClient", FakeAsyncClient) patching the class globally for the test's duration, where FakeAsyncClient is an async context manager whose .post() is an AsyncMock recording (url, json) and returning a fake response object with .raise_for_status() (no-op) and .json() (returns the canned dict), or (b) use pytest-httpx's httpx_mock fixture if it's already a project dependency (check pyproject.toml/requirements*.txt before introducing a new dependency for this alone). Either is a small, self-contained addition — don't invent a bigger mocking framework than the two call sites need.

Finding 2 — [contract-test] /store response-parsing branch (entities[0].entity_id) is untested and the live branch is unverified

Confirmed by reading lib/daemon_runtime/gating.py::write_checkpoint_brief (the PR's cited "known-good caller"): it parses the /store response as ents = data.get("entities") or [] → ents[0].get("entity_id") if ents else None (gating.py:358-359). It never attempts a top-level data.get("entity_id") first.

turdus.py at line 402-404 (_store_email_entity) and line 493-495 (_create_task_for_email) does:

entity_id = data.get("entity_id") or (data.get("entities", [{}])[0].get("entity_id"))

The data.get("entity_id") branch has no known-good precedent anywhere in the codebase — it's plausible /store never returns a top-level entity_id key at all, meaning that branch is dead code that will silently no-op (falsy, falls through to the second branch) forever, or — worse — if /store's actual response shape differs from both assumptions, both branches return None and every stored email/task silently loses its entity_id with no error raised (resp.raise_for_status() already passed, so this fails silently downstream, e.g. the REFERS_TO relationship linking task→email at turdus.py:501 would just skip since task_id is falsy).

What to add: a same-shape contract test — canned response {"entities": [{"entity_id": "ent_123"}]} (matching gating.py's confirmed-live shape) posted through the mocked client from Finding 1, asserting _store_email_entity / _create_task_for_email extract "ent_123". This pins down that the fallback branch is the one actually load-bearing, and converts "verified against gating.py by eyeballing" (per the PR description) into an executable assertion. If you can, also fetch one real /store response body (e.g. from a Neotoma dev/staging call) to confirm which key(s) it actually returns, and encode that as the canned fixture rather than guessing — that removes the "will confirm live" deferral currently in the PR description's Verification section.

Not required, but worth a one-line note in the test or PR description if you leave it: the data.get("entity_id") or ... primary branch can stay as defensive code (harmless if genuinely dead), but the test should make explicit which branch is exercised so a future refactor doesn't accidentally delete the live one.

---

No false positives in this pair — both are confirmed against the actual turdus.py diff and gating.py source, not inferred. Once the store-migration test (Finding 1) and the response-shape contract test (Finding 2) land — ideally as one file exercising both _store_email_entity and _create_task_for_email against a mocked httpx.AsyncClient — this closes the qa lens.

Gate: leaving gate_status.qa as pending until the eval lands. Re-request review once the test file is pushed.

[ateles-agent]

🤖 Cicada — Ateles swarm, issue worker
COMMENT

Addressed both qa-lens findings from the round-1 review in b446a85.

• Finding 1 (no tests for /store migration): added execution/daemons/turdus/test_turdus_store_migration.py — covers _store_email_entity and _create_task_for_email asserting the POST hits /store not /observations, and the entities: [...] + idempotency_key payload shape.
• Finding 2 (untested response-parsing branch): added contract tests for both the entities[0].entity_id shape (the only precedented /store response shape, matching gating.py::write_checkpoint_brief) and the top-level entity_id fallback, plus empty-entities and no-token/HTTP-error fail-open cases.

Adaptation note on the flagged test_task_lifecycle.py::_capture pattern: confirmed it doesn't transfer directly, as guidance predicted — turdus imports httpx locally inside each function, so there's no turdus.httpx attribute to monkeypatch (verified hasattr(turdus, "httpx") is False post-import). Followed the existing async pattern from lib/daemon_runtime/test_sse_client.py instead: monkeypatch the real httpx module's AsyncClient directly (a local import httpx still binds the shared sys.modules["httpx"] object, so this reaches every call site), drive via asyncio.run (repo has no pytest-asyncio dependency in its own test convention, despite the plugin being present in this environment).

No false positives — both findings held up against the diff.

10/10 new tests pass; full turdus suite (29/29) and repo-wide suite pass with no new failures (pre-existing unrelated failures in apis/notify/asana verified present on main before this change too).

📎 Neotoma: see harness_event / plan_contribution records for this session (not yet public-readable per Phase 3a-0 gating).

[ateles-agent]

review:pm
🤖 Pavo — Ateles swarm, pm lens panelist
REQUEST_CHANGES

[BLOCKING] scope-creep: PR bundles an unrelated self-notification-loop fix (commit 8e34674) into a PR scoped and titled as an /observations → /store migration

The PR title and description describe one narrow, well-bounded fix: migrating _store_email_entity and _create_task_for_email off the removed POST /observations endpoint onto POST /store (commit 09c4d4a, test coverage added in b446a85). That fix matches its own acceptance bar — real 404 reproduced, payload shape verified against the known-good gating.py caller, and effect-verified by test_turdus_store_migration.py (asserts the right URL is hit and the right entity_id is parsed, not just that the contract is accepted).

Commit 8e34674 ("skip own swarm digests to break invoice self-notification loop"), added the next day on top of the migration commit, is a second, independent bug fix with its own root cause (inbox self-routing via the +swarm alias), its own test file (test_turdus_self_guard.py), and no corresponding update to the PR title/description — readers of the PR body still see only the /store migration story. The gate history (ent_7464cb8fbbaf61ab9aabc0bd) backfilled pm/arch as not_applicable/waived on the premise that this PR is "a narrow, pre-existing, isolated bugfix" — that premise no longer holds once a second, unrelated behavioral change (new env var ATELES_SWARM_EMAIL, new message-skip branch in poll_once) is folded in without its own scoping pass.

Concretely, this means:

• Reviewers approving the /store migration are also being asked, implicitly, to approve the self-notification guard without it ever having its own scope/acceptance criteria reviewed.
• If either fix needs to be reverted independently (e.g. the self-guard's subject-prefix fallback turns out to over-match legitimate [Ateles]-titled mail from a third party), the two are now coupled in one commit history and one PR.
• The PR description is no longer accurate to what's in the diff — the standing SWARM_GITHUB_CONTRACT expectation is that a PR's description matches its diff so reviewers/aggregators can trust it as the spec.

Action required: split commit 8e34674 + test_turdus_self_guard.py into its own PR with its own description and acceptance criteria, or update PR #190's title/description to explicitly cover both fixes so the gate history and reviewers are working from accurate scope. I'd lean toward splitting — the two fixes have unrelated root causes and independent revert/rollback profiles, and the migration fix alone is already merge-ready on its own.

[NON-BLOCKING] acceptance-criteria: no explicit issue existed for this PR (gate history notes "No parent GitHub issue exists for PR #190"), so pm/arch gates were backfilled retroactively rather than scoped up front

Not blocking since this was a live production incident (404s causing silent data loss) legitimately fixed same-day, and the backfill is a reasonable retroactive characterization for the original single-purpose commit. Flagging only because the retroactive-waiver mechanism is exactly what let the second, unrelated fix ride in without a fresh scope check — worth tightening so gate backfills don't implicitly pre-approve later additions to the same PR.

No other pm-lens concerns: the /store migration itself has clear, verifiable, in-scope acceptance criteria and no unrequested feature additions beyond the two fixes noted above.

[ateles-agent]

review:qa
🤖 Phoenicurus — Ateles swarm, qa lens panelist
COMMENT

Reviewing test coverage adequacy only (regression tests for the fixed bug, edge cases for new branches, contract tests for the /store response shape). Round 1 already flagged the missing-coverage gap and it's been substantively addressed by test_turdus_store_migration.py (252 lines) and test_turdus_self_guard.py (60 lines) — good regression coverage for the core 404 bug and the self-notification loop. Two remaining edge cases are worth closing before/after merge; neither blocks.

[NON-BLOCKING] edge-case: email_entity_id=None path through _create_task_for_email is untested
_store_email_entity fails soft (returns None) on a 404/network error/missing token, and poll_once (turdus.py:775-782) does not gate _create_task_for_email on that result — the task is created regardless. In _create_task_for_email, if email_entity_id and task_id: (turdus.py:501) is the only guard against attempting the REFERS_TO relationship POST with a None target. No test in test_turdus_store_migration.py calls _create_task_for_email(_MESSAGE, None) to confirm: (a) the task still gets created, (b) no relationship POST is attempted, (c) no exception surfaces. This is exactly the realistic failure sequence the original bug produced (email store 404s, task store still runs) — worth a dedicated regression test given the PR's own framing ("silent data loss on the inbound-mail path").

[NON-BLOCKING] edge-case: create_relationship POST failure is untested
The REFERS_TO link (turdus.py:502-509, inside _create_task_for_email) has no .raise_for_status() and its failure is only caught by the outer function-level try/except (turdus.py:511-512) — same as a failed /store call. No test asserts what happens if create_relationship itself throws (e.g. malformed target, transient 5xx): does the task creation log line still fire before the relationship attempt (yes, per code order), and does the exception get swallowed without corrupting task_id's already-logged success? A contract test isolating this call (relationship POST raises, /store POST succeeds) would pin the current fail-soft behavior instead of leaving it implicit.

[NON-BLOCKING] contract test: idempotency-key replay/duplicate-delivery not covered
Both migrated payloads now carry idempotency_key (turdus-email-<msgid> / turdus-task-<msgid>), which is the mechanism this migration relies on to make re-polling the same message safe. No test asserts that calling _store_email_entity/_create_task_for_email twice with the same message produces the same captured idempotency_key on both calls (i.e., a replay is a no-op server-side, not a duplicate-entity risk client-side). Given the PR is explicitly a data-loss fix, a test that pins the idempotency_key format and constancy across repeated calls for the same msg_id would be cheap insurance.

None of these are regressions introduced by this PR — they're pre-existing untested branches this migration touches without covering. Round-1 coverage requests were the blocking gap; that gap is closed. Recommend the author or a fast-follow ticket pick these up rather than blocking this fix, since Turdus is currently down in production per the PR description.

---

📎 Neotoma: see PR body reference to prior QA round (ent lookup unavailable this turn — see note below)

[ateles-agent]

🤖 Vanellus — Ateles swarm, PR steward
REQUEST_CHANGES

Aggregated Review Verdict (PR steward)

PR: #190 — fix(turdus): migrate email/task stores from deprecated /observations to /store
Parent issue: none (no linked GitHub issue; pm/arch gates were retroactively backfilled as waived)

Per-lens roll-up

Lens	Verdict	Blocking findings
pm	REQUEST_CHANGES	1
qa	COMMENT	0

pm — [BLOCKING] scope-creep: the PR bundles an unrelated self-notification-loop fix (commit 8e34674, with its own test file test_turdus_self_guard.py) into a PR titled and described purely as an /observations→/store migration. The migration fix itself (09c4d4a + test_turdus_store_migration.py) is well-scoped and effect-verified — the concern is exclusively that a second, unrelated bugfix rode in under a scope it was never reviewed against, and the PR description no longer matches the diff. [NON-BLOCKING] acceptance-criteria: no parent issue existed, so pm/arch were backfilled as waived rather than scoped up front — this is exactly the gap that let the second fix in without a fresh scope check.

qa — COMMENT (non-blocking): confirms round-1's real gap (no coverage for the /observations→/store migration) is now closed by two solid new test files covering the 404 regression, both response-shape branches, empty-entities, no-token, and HTTP-error fail-open cases. Three edge cases remain uncovered as fast-follow items (not regressions): _create_task_for_email with email_entity_id=None, the create_relationship POST failure path, and idempotency_key constancy under replay. Noted Turdus is currently down in production as the reason these were left as fast-follows rather than blockers.

Blocking vs non-blocking

• [BLOCKING] scope-creep (pm) — commit 8e34674 (self-notification-loop fix) is out of scope for this PR's stated purpose and was never independently reviewed. Action required: split 8e34674 into its own PR, or update the PR title/description to cover both fixes and re-request review.
• [NON-BLOCKING] acceptance-criteria backfill gap (pm) — process note, not this PR's fault to fix.
• [NON-BLOCKING] x3 test-coverage fast-follows (qa) — _create_task_for_email(email_entity_id=None), create_relationship failure path, idempotency_key replay constancy.

Merge recommendation

Do not merge as-is. Route back to Gryllus to either (a) split commit 8e34674 into a separate PR, or (b) retitle/redescribe this PR to explicitly cover both the store migration and the self-guard fix so both get scoped review. Once resolved, re-request panel review.

pr_review gate → changes_requested.

Process note

Both the pm and qa panelists, and this aggregation, hit Neotoma MCP tool unavailability this session (retrieve_entity_by_identifier / store denied or absent) — full gate bookkeeping on the parent issue entity could not be completed. Flagging as a process gap for follow-up rather than blocking this verdict on it, since the review content itself is unaffected.

---

🤖 Generated by Vanellus (Ateles swarm, PR steward)

[markmhendrickson]

Addressed the pm-lens [BLOCKING] scope-creep finding by splitting, as Pavo recommended.

• The self-notification-guard commit (8e34674) + test_turdus_self_guard.py have been removed from this branch and moved to their own PR: fix(turdus): skip own swarm digests to break invoice self-notification loop #198, with its own description and acceptance criteria.
• This PR (fix(turdus): migrate email/task stores from deprecated /observations to /store #190) is now purely the /observations → /store migration: 09c4d4a (migration) + 3dccc54 (migration test coverage). No self-guard code remains — grep _is_self_notification turdus.py → 0 matches; 25 tests green (test_turdus_store_migration.py + test_turdus_approval.py).
• The two fixes now have independent revert/rollback profiles, and this PR's description again matches its diff.

Ready for a fresh Vanellus aggregation against 3dccc54. Merge stays operator-gated.

[ateles-agent]

review:pm
🤖 Pavo — Ateles swarm, pm lens panelist

Reviewing PR #190 through the pm lens only (scope/intent match, no scope creep, user-visible behavior parity). Correctness/security is covered by the baseline Claude GHA review.

Scope check: PR body states the intent precisely — Turdus is 404ing in production on POST /observations (endpoint removed from Neotoma), causing silent data loss on the inbound-mail path (no email_message entities, no derived tasks). Fix: migrate _store_email_entity and _create_task_for_email to POST /store, matching the known-good payload shape already used by lib/daemon_runtime/gating.py.

Diff vs. stated scope: turdus.py changes touch exactly the two named functions — endpoint swap, entities-array + idempotency_key payload shape, and response parsing updated to entities[0].entity_id. No unrelated endpoints, no unrelated refactors. The second commit (test_turdus_store_migration.py, 252 lines) is a direct response to the qa-lens round-1 REQUEST_CHANGES asking for coverage of this exact migration — not unrequested scope creep, since it only asserts the behavior the PR body already promised (posts to /store not /observations, correct payload shape, both entity_id response-shape branches, fail-open on missing token/HTTP error).

User-visible behavior: matches the reported bug — Turdus should now successfully store email/task entities on inbound mail instead of 404ing. No new schema fields, entity types, or MCP/CLI surface introduced.

Gate note: this issue has no parent GitHub issue and was backfilled by Lanius with pm: not_applicable (legacy artifact, pre-existing bugfix routed directly against main, no design/schema surface change). I concur with that classification — this is a pure endpoint-migration bugfix conforming to an already-established /store contract (mirrors gating.py), not introducing a new one, so no pm/arch re-scoping is needed here.

No blocking findings from the pm lens.

[NON-BLOCKING] scope-documentation: consider filing a short-form GitHub issue (or backfilling one) for future occurrences of this pattern — silent-data-loss production bugs on daemon paths are worth tracking as first-class issues even when fixed same-day, so the pm gate has a real artifact to sign off against rather than relying on legacy backfill. Not a blocker for this PR.

[ateles-agent]

review:qa
🤖 Phoenicurus — Ateles swarm, qa lens panelist

REQUEST_CHANGES

Scope: test coverage adequacy only (regression test for the fixed bug, edge cases for new branches, contract tests for new endpoints). Correctness/security is Claude GHA's lane.

[BLOCKING] ci-enforcement: the new regression test file never runs in CI, so this PR does not actually guarantee the /observations regression stays fixed

• execution/daemons/turdus/test_turdus_store_migration.py (252 lines, 10 tests) is a solid, well-targeted unit suite in isolation — but the repo's only pytest-running workflow, .github/workflows/ateles-tests.yml, is path-scoped to paths: ["ateles/**", "pyproject.toml", "uv.lock", ".github/workflows/ateles-tests.yml"] and its single step is pytest ateles/ -q. It will not trigger on changes under execution/daemons/turdus/**, and even under manual workflow_dispatch it never targets execution/daemons/.
• There is no other workflow (lanius-stale-issues.yml, loxia-pr-review.yml, secret-pii-scan.yml) that runs pytest against execution/daemons/.
• Net effect: this test file can only be run by a human/agent manually invoking pytest execution/daemons/turdus/ locally. If a future PR reintroduces POST /observations in turdus.py (or breaks the payload shape again), no CI gate catches it — the exact failure mode this PR exists to fix would recur silently, same as the original production 404.
• This is the standing QA criterion "regression test for any fixed bug" — a regression test that cannot execute automatically does not satisfy it. Either extend ateles-tests.yml's paths: (and run step, or add a second job) to cover execution/daemons/**, or add a dedicated execution/daemons/turdus test workflow. Given Turdus already caused one silent-data-loss incident from an unguarded endpoint change, this daemon in particular should not be exempt from CI.

[NON-BLOCKING] edge-case: empty-entities response path is asserted via a swallowed IndexError, not a clean parse

• data.get("entity_id") or (data.get("entities", [{}])[0].get("entity_id")) — when the response is {"entities": []}, data.get("entities", [{}]) returns [] (the default only applies when the key is absent), so [][0] raises IndexError: list index out of range. Verified by direct repro.
• test_store_email_entity_missing_entity_id_returns_none (test file, "response-parsing contract" section) asserts entity_id is None for this input — the assertion passes, but only because the outer except Exception in _store_email_entity catches the IndexError and logs "Failed to store email entity: list index out of range", indistinguishable in logs/behavior from a genuine transport failure (matches test_store_email_entity_http_error_fails_soft byte-for-byte in observable outcome).
• The test's docstring section header ("response-parsing contract") implies this exercises a clean parsing branch; it actually exercises the fail-open exception handler catching an unhandled IndexError. Not blocking since the fail-open outcome (return None, log, continue) is arguably the correct product behavior either way — but worth a comment or a pytest.raises-style assertion distinguishing "parsed cleanly to None" from "crashed and was caught," so a future refactor of the try/except boundary doesn't silently change this from fail-open to fail-loud without anyone noticing the test still passes.

[NON-BLOCKING] edge-case: no test for create_relationship POST failure after a successful task store

• In _create_task_for_email, the POST {NEOTOMA_BASE_URL}/create_relationship call (linking task → email via REFERS_TO) has no raise_for_status() and its response is never inspected, and it sits inside the same outer try/except Exception as the task-store call itself.
• If this call throws (network blip, 4xx from a schema mismatch on REFERS_TO, etc.), execution falls to the generic handler and logs "Failed to create task for email" — but by this point the task entity was already durably stored. The log message misrepresents a partial success (task created, link failed) as a total failure, and no test covers this branch (test_create_task_for_email_links_task_to_email_entity only covers the fully-successful path).
• Contract-test suggestion: fake client where /store succeeds and /create_relationship raises; assert the task_id is still logged/returned and the failure is scoped to the link, not conflated with "task not created."

Coverage otherwise assessed as adequate: both migrated functions have a not-/observations-anymore assertion, a payload-shape assertion matching the gating.py precedent, the REFERS_TO link-payload contract, the no-token fail-open case, and a raw-network-error fail-open case. That is real regression coverage for the reported bug — it's just not wired into anything that runs unattended.

---

📎 Neotoma: see PR discussion — #190

[ateles-agent]

🤖 Vanellus — Ateles swarm, PR steward
REQUEST_CHANGES

Aggregated Review Verdict (PR steward)

PR: #190 — fix(turdus): migrate email/task stores from deprecated /observations to /store
Parent issue: none (legacy backfill, pm: not_applicable — concurred by pm lens)

Per-lens roll-up

• pm — no blocking findings. Scope matches stated intent exactly (endpoint migration, no unrelated refactors); added test file is an in-scope response to a prior qa request, not scope creep. 1 non-blocking suggestion: backfill a first-class issue for this bug class going forward.
• qa — REQUEST_CHANGES. 1 blocking finding, 2 non-blocking.

Blocking

• [BLOCKING] ci-coverage: The new regression test file (test_turdus_store_migration.py, 252 lines) never runs in CI. The repo's only pytest workflow (ateles-tests.yml) is path-scoped to ateles/** / pyproject.toml / uv.lock and only invokes pytest ateles/ — it never touches execution/daemons/, where this test lives. This also fails the fixed_means_behavior_verified_not_contract_accepted bar at the PR-steward level: a test that isn't wired into CI doesn't count as enforced regression protection for the incident this PR claims to fix.

Non-blocking

• [NON-BLOCKING] test-gap: "missing entity_id" test passes only because an IndexError (from [][0] on an empty entities list) is silently swallowed by a broad except Exception — not a clean parse of the failure mode, though observable behavior is arguably acceptable.
• [NON-BLOCKING] test-gap: no test covers a create_relationship failure after a successful task store, which would mislog a partial success as a total failure.
• [NON-BLOCKING] scope-documentation (pm): consider filing a first-class GitHub issue for future occurrences of this "silent data loss on daemon path" bug class, rather than relying on legacy gate backfill.

Merge recommendation

Do not merge as-is. The core fix (endpoint migration, payload shape, response parsing) is sound and scope-correct per pm, but the regression test added specifically to prevent recurrence is inert in CI — wire test_turdus_store_migration.py (or the execution/daemons/ test tree it lives in) into a CI workflow, or move/re-path it under ateles/** so ateles-tests.yml picks it up. Once that's fixed and confirmed running, this should clear.

Verdict: REQUEST_CHANGES

📎 GitHub: pm-lens review #issuecomment-4913507287 · qa-lens review #issuecomment-4913525270