CedarCopilot wants to merge 3 commits into staging from fix/dm-container-kind
Live on prod, no production signal yet
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
Verification reached its 120s wall-clock budget before a tied verdict. Libra is keeping this intent verifying until the next check.
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
Verification reached its budget before a verdict.
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
Unable to complete verification because the available telemetry queries returned no matching warning or task-operation spans, and source reads were blocked by the character budget.
Libra has verdicts on 0 of 8 tracked behaviors on prod; 8 are still being checked. Libra checks hourly for 3 days after each deploy.
Three unrelated fixes, sharing a branch rather than a subject. The first two are the remaining Greptile findings from #2669, which merged before they landed; the third is the task-completion work below and can be reviewed on its own.
fix(coaching): the weekly cron was written down but never armedseed-coaching-agent.ts wired a meeting trigger and a weekly cron into the playbook XML and saved it with a raw writeDocument. A PLAYBOOK.md is a compiled document , what the scheduler and router read is metadata.playbook_manifest, and a raw write updates the content while leaving that manifest untouched. The triggers were visible to anyone opening the playbook and invisible to everything that would act on them, with the script printing wired: and exiting zero. The seeding looked complete and the agent simply never ran.
Now routed through writeDocumentGuarded, which exists for exactly this and dispatches on the path, so it takes the user- or org-scoped playbook branch to match --level without being told which. The write returns a summary of what it armed, read off the manifest it just compiled; the script asserts the meeting trigger and the requested cron are both present and fails loudly otherwise, so a manifest that came back without them can't reproduce the same green-but-inert result.
fix(sidebar): the adapter asserted a projection it never receivesThe sidebar cast the listConversations response through any, Record<string, unknown> and object on its way to HydratedConversation. That type describes the detail projection; the list ships strictly less. The casts asserted something untrue and switched off the only check that would have said so.
Removing them surfaced three real mismatches , a custom field arrives with no working-memory provenance, latestEvent is an overview event, and the conversation has no lastReviewedAt / conversationScope / overviewItems.
One was already live. buildHaystack searched latestEvent.emailEvent?.subject and latestEvent.summary; neither exists on an overview event, so both were always undefined and neither contributed a word to free-text search. Subject search still works , an email event's title is its subject (title: message.subject || '(No subject)') and title is what the list carries. The two dead branches are gone, and the test that covered them fabricated a detail-shaped event to pass, so it now uses the real shape.
SidebarConversation is inferred from the adapter rather than written out, so it is by construction whatever the projection produces and server-side drift lands as a compile error instead of a blank row. It is wider than HydratedConversation in the two places they differ, so the sidebar helpers still accept a detail conversation and nothing outside conversationsPage/ changes type.
I tried the alternative first , widening HydratedConversation itself , and backed it out: it produced 28 errors across 9 detail surfaces (10 in workingMemoryCard.tsx alone) that legitimately hold full entries and shouldn't have to guard.
fix(tasks): completion was lost on reload, and the check-mark never cleaned up its draftTwo defects on the task-completion path, reported independently by Zach (#cedar-concentrate:
"I check them as done. I click refresh and then it appears again every time") and Mihir
(#cedar-invoicebutler).
optimisticCompleteTaskDelayed deferred the server write inside a setTimeout behind the undo
toast. A reload, tab close or crash in that window took the timer down with the JS context:
completeTask never fired, the in-memory mask did not survive either, and the row came back on
the next fetch , with no completed_at and no server-side trace the user had ever closed it.
Client-side navigation was fine; only a hard reload lost the write, which is exactly what Zach
was doing.
The deferral was guarding a side effect that d
Libra has not measured any production surfaces for this change yet.