Epic Completion Audit

eva-core/isolation/policy.py:15-27,63-74 _decide() now only compares caller.principal_id != target.principal_id; the caller.zone != target.zone branch and AuditAction.CROSS_ZONE_ATTEMPT were removed outright (DEV-NOTES.md correction M), a new test (test_isolation.py:84-102) asserts a GENERAL caller can now read MNPI data for the same principal, and the red-team corpus had its cross-zone case deleted with the comment “this is no longer a real attack” (security/corpus.py:40-42). This single change downgraded verdicts across E11-S3/S4, E13-S5, E15-S2/S5, E16-S7, E17-S6, E18-S5/S6, and E19-S7 from “unreachable in practice” to “the enforcement primitive no longer exists to wire anything into.”

At least seven independent subsystems are wired at boot and never invoked by any route/MCP tool: PlaybackProgressTracker (wiring.py:548-549), BatchUndoStore (wiring.py:551-552, despite passing unit tests), DeviceContextStore (wiring.py:545-546, contradicting its own docstring), RendererPriorityQueue (wiring.py:542-543), CalibrationPushService (wiring.py:557-560), IdentityResolutionEngine (wiring.py:297-299), and HashChainedAuditLog (wiring.py:197-199). This is the dominant failure mode in the codebase — correct, tested logic that the application never actually calls.

RelationalGraphService.evaluate_drift (arbiter/relationships.py:113, max(cadence_score, tone_drift)) and the production-wired SupabaseRelationshipStore.evaluate_drift (relationship_store.py:169, identical max()) both violate “cadence primary, tone corroborator” (E7-S2). Separately, HashChainedAuditLog (real hash chain, zero callers) and SupabaseAuditSink (live, durable, but its docstring's claimed audit_log_set_hash DB trigger doesn't exist per migrations/010_audit_log.sql) leave the append-only audit log split into a chained-but-dead half and a live-but-unchained half (E9-S1). And two colliding ScenarioAnalysis dataclasses exist — the correct advisory one in relevance.py:10-16 and a directive one in evaluator.py:47-53 that emits recommendation text like “Activate contingency plan” (E6-S12).

memory_result.dart expects id/content/entity_type/timestamp/citations:List<String> but the backend sends fact_id/subject/predicate/object_value/citations:List<Citation> (E9-S2). draft_item.dart expects subject/content/pillar/draft_type but GET /keeper/drafts returns BriefDraft shaped as draft_id/principal_id/zone/brief_type/state/sections (E2-S3, E12-S4). Both screens are reachable and call the correct endpoint, but would render empty/default values against real data.

eva_recall_facts (registry/keeper.py:122-143) drops citations that the equivalent REST routes (keeper_routes.py:40-58,284-293) serialize correctly (E3-S2, E9-S2). Separately, the eva_forget tool description (catalogue.py:424-430) claims a “24-hour propagation SLA,” but the wired handler (webhooks.py:138-157, registry/compliance.py:9-33) only ever calls request_forget() — ForgetEngine.propagate() (erasure.py:84-102) has zero production callers outside tests (E9-S4, E15-S3/S4). Agent-facing tool descriptions are actively misleading about what the system does.

scheduler.py:161 calls relevance_engine.score(...), but the object wired at that name (wiring.py:444-445) is a RelevanceScenarioEngine whose only method is score_event(...) (relevance.py:24) — every call raises AttributeError, caught by a bare except at scheduler.py:166-168, with no test covering _cartographer_crawl (E6-S1). This means the pre-existing 4-hour crawl pipeline is currently non-functional in production, a regression beyond the original “interval too slow” finding.

draft_review_screen.dart / keeper_providers.dart call GET /keeper/drafts, which is backed by LivingDraftManager's BriefDraft (morning-brief queue) — not Correspondent's queue_for_principal() (correspondent.py:665), the actual E5 email-draft/escalation queue, which is referenced only by its own unit test and exposed via no route or MCP tool anywhere (E5 epic_note, E8-S1, E12-S4). This also means E8-S1's “memo variant” premise fails doubly: there's no shared brief-variant abstraction to extend, and the story's target draft system is invisible to the app.

morning_brief_widget.dart implements real play/pause audio control with no seek/scrub/replay (E1-S4); pillar_chat_page.dart implements a real tap-and-hold record-transcribe flow, but it's generic per-pillar chat input with no 5-minute cap and no debrief/meeting scoping (E4-S1, E4 epic_note); and memory_search_screen.dart plus the per-pillar chat box are two disconnected, non-prominent query surfaces rather than the single global query bar the spec calls for (E3-S4). Each upgraded a story from NOT_STARTED to PARTIAL without closing the actual gap.

E19: `SubscriptionService._transition` publishes `SUBSCRIPTION_DOWNGRADED` (`eva_domain/subscription/service.py:165`) but `EVA_Bureau/src/eva_bureau/consumers.py` has zero subscription/downgrade references — no consumer exists anywhere. E15: `ComplianceConsumer` is fully coded and unit-tested (`EVA_Bureau/tests/test_consumers.py:94-120`), but `consumers.py:311-335`'s `start_consumers()` never instantiates it — so `propagate()`/`FORGET_COMPLETED`/`FORGET_SLA_VIOLATED` never fire in production, identical net behavior to the pre-session baseline despite all supporting logic existing. Same root cause twice: engine + tests shipped, the one-line production-startup wiring step was skipped both times.

E10-S2: persistence, reviewer actions, audit trail, and MCP tools are all genuinely wired end-to-end — but `resolve()` (`identity.py:43-76`) itself has no production caller anywhere, so the review queue the new tools expose can never populate from real data. E19-S1: `require_active_subscription` is real and tested but called from exactly one route (`brief_routes.py:114-115`), not any Editor/Cartographer/Arbiter surface — “lights up pillars” as a concept isn't built, only its primitive. Same pattern found independently in E13 (all 5 stories): correct, unit-tested domain logic with no route/MCP tool ever calling it.

E16's calendar rebuild (599 lines vs. ~120-line prototype) mirrors the pre-existing `draft_manager`/`commitment_tracker` Supabase-switch pattern exactly (`wiring.py:376-393`), landing 6/10 stories at full DONE with 34 passing tests. E17's `CommitmentChaseEngine` explicitly models itself on `SentinelAlertManager`'s cooldown pattern (`commitment_chase.py:12-17`), with 21 passing tests. This is the strongest evidence the pass is disciplined engineering, not verdict-chasing.

E17-S1: `due_date` is accepted by the MCP handler (`registry/keeper.py:91-115`) but `CreateCommitmentRequest` on the REST route (`keeper_routes.py:174-198`) has no `due_date` field at all — an HTTP caller cannot set a deadline at creation, only MCP callers can. This divergence didn't exist before `due_date` was added; it's a net-new risk from this build pass, not a pre-existing gap.

`commitment_chase.py:12` explicitly docstrings “no real push/email” for chase reminders (E17-S3, graded PARTIAL). E15-S2's privileged-channel access control (`audit_query.py` `CounselRegistry`) is an env-var allowlist stub, not per-caller DB roles — also self-documented as such. Graded correctly against the codebase's existing bar, but Phase 2 planning should not read “DONE”/“PARTIAL” here as “a human receives a notification.”

Every UI-facing story (E16-S1 re-auth UX, E10-S1 confirmation-prompt UI, etc.) is blocked on the frontend repo not existing on disk at all — not on backend incompleteness. Any Phase 2 sequencing that treats these as “blocked on backend, unblock next” is mis-scoped.

ComplianceConsumer and a new SubscriptionConsumer are now both instantiated in `consumers.py`'s `start_consumers()` (previously missing entirely) — E15-S3/S4 (forget auto-propagate) and E19-S2 (credential revocation on downgrade) moved from PARTIAL/NOT_STARTED to DONE as a direct result. Three real endpoints (`POST /keeper/memory/search`, `GET /keeper/memory/facts/{subject}`, `eva_recall_facts`) that previously bypassed E13-S5's refusal check entirely now route through it — that story moved to DONE. `eva_resolve_identity` and `eva_open_hr_thread`/`eva_close_hr_thread` give resolve() and HR-thread state their first real callers outside tests (E10-S2 now DONE, E13-S1 evidence improved though still blocked on the scheduler hardcoding zone=GENERAL). Net: 5 verdict upgrades to DONE, zero epics fully closed — remaining gaps in E13/E19 are real feature work (scheduler zone-awareness, production-path Supabase store parity), not more wiring.

Pattern repeats across E1 (persona/zone-prosody/hedging/EOD-budget all real+tested now, but E1-S2/S4/S5 stay PARTIAL because the fallback-path-only or frontend-absent caveats survive), E2 (device-context and batch-undo went from zero backend callers to fully wired+tested REST routes — E2-S4/S8 evidence rewritten, verdict held at PARTIAL solely because no Flutter UI drives them), E3 (the scheduler now genuinely auto-fires 30 minutes before a meeting and populates a real draft — E3-S1 stays PARTIAL because "there is nowhere for the user to see it" is still literally true), and E5/E18 (whistleblower non-demotability and Scribe's edit lifecycle are the two cleanest fixes — a documented bug closed exactly as described, and a documented missing method now exists — landing at DONE and PARTIAL->DONE respectively). One correction along the way: this pass's own indentation mistake silently turned half of CalendarOrchestrator's methods into nested functions inside a newly-added module function, caught immediately by the resulting test failures rather than by review.

CalibrationConsumer now subscribes to CALIBRATION_UPDATED and calls schedule_push() (previously nothing subscribed to that event at all); a new _calibration_fast_track callback is registered via register_callback() in EvaScheduler.configure() (previously zero production call sites, confirmed independently by three separate prior-audit grep passes under three different epics) and re-scores relevance/drift for just the triggering principal within the debounce window — proven end-to-end with the debounce shrunk to 0.01s rather than trusting the pieces in isolation. Net: E6-S5 and E14-S3 both moved NOT_STARTED→DONE, E14-S1 and E4-S2/E4-S3 moved toward PARTIAL with substantially rewritten evidence. Separately, E7's SupabaseRelationshipStore — the store actually used in production — was rewritten to delegate to the real RelationalGraphService instead of independently reimplementing it, which didn't flip any E7 verdict but collapsed two independently-drifting buggy implementations (the cadence/tone max() bug, the missing 4-layer Confidence Architecture, the never_flag reload bug) into one, fixing the never_flag bug outright as a byproduct and leaving the remaining known bugs fixable in exactly one place going forward. Zero epics fully closed — E4/E6/E7/E14 all still have real, unaddressed frontend and product-decision gaps the evidence spells out story by story.

BriefType.MEMO now exists and is accepted end-to-end (E8-S1); a new eva_memo_inline_query MCP tool answers free-text questions against a memo draft via a shared eva_domain.keeper.memo_query.answer_query(), the same function E3's chat query-bar now calls too — one implementation instead of two independently-drifting copies (E8-S2); VoiceDeliveryBridge.to_ssml() intercepts PRIVILEGED/MNPI/HR memo sections outright and a new memo_citation_sections() helper exposes exactly what to render as a citation cue card (E8-S3). None reached DONE: E8-S1's actual ask — one shared composition path across voice/cue-card/memo instead of the duplicated paths E2-S1/E12-S5 already documented — was correctly left untouched rather than faked with a bigger refactor out of proportion for this pass; and all 3 stories are backend-only, since no memo-reading UI exists in Flutter to make any of this reachable by a principal.

E9-S4's "propagate() never invoked in production" verdict was never re-checked against the Phase-1.5 ComplianceConsumer fix (built for E15-S3) because E9 was never in scope for any prior pass — reading consumers.py directly confirmed the exact same epic-agnostic consumer already made this true, so the fix was free: a documentation correction, not new code. Where real gaps existed, they closed cleanly: E9-S1's hash-chaining was unified into one shared, tested algorithm (eva_contracts.contracts.audit.hash_audit_event/verify_hash_chain) used by both InMemoryAuditSink and the production SupabaseAuditSink, which now actually populates the prev_hash/this_hash columns migrations/010 always had; E9-S3's correct_fact/retract_fact is a genuinely new mechanism built into both the in-memory and production (Neo4j) graph stores; E12-S6's "implemented backwards" bug (interrupt_locked silently re-locking with no signal anything changed) is fixed in both LivingDraftManager and SupabaseDraftStore, the latter gaining its first-ever test file in the process. E12-S3 shows the limits of a bounded pass honestly: the queue's producer side (push) is now real and wired end-to-end, but its consumer side (pop_next) still has zero callers, so nothing yet turns a queued P0 into an actual real-time re-delivery — evidence was rewritten to say exactly that rather than rounding up to DONE.

S4/S6 need a Flutter UI (scrub controls, onboarding tone-capture) and the Flutter frontend repo was confirmed to no longer exist anywhere on this machine at all (both previously-referenced paths checked directly) — a stronger, more definitive absence than earlier sessions' per-epic "not found at this path" notes. S2/S7 need the primary, most-used brief delivery path (OpenClaw-authored free-form prose) to carry structured per-fact confidence to hedge against or restructure — exactly the gap the Integrity Gate v2 design (proposed, not built, explicitly deferred by the user this session) exists to close; building it now to unblock two E1 stories would be solving the wrong problem in the wrong order. Only S1 and S5 had a real, bounded gap: S1 gained a genuine T-30 pre-warm for pre-meeting briefs (populate_pre_meeting_draft already builds that draft's content deterministically ahead of time, so there was finally something real to warm) plus a content-keyed cache so the warm-up isn't wasted work, while the primary morning-brief path is untouched since OpenClaw builds and delivers its draft in one T-0 job with nothing to pre-warm from; S5 gained the specific "adaptive last-meeting-anchor" logic its own gap text named, word-budgeted like every other line. Neither reaches DONE — both were narrowed exactly as far as a bounded, dependency-free pass allows, and no more.

S4/S5/S6 needed a Flutter surface that didn't exist a few turns earlier; once it was back on disk, each closed with real, tested, wired code (scrub/replay via drag-to-seek plus a word-count-estimated section-replay button for S4; a full AudioPlayer in EodBriefScreen for S5; a new onboarding route + screen for S6, the first real caller anywhere of VoiceProfileManager.update_from_correction). S7 closed because the Phase 2 flip's biggest structural change — eva_submit_brief_plan actually rendering an ACCEPTED plan via BriefComposer into the real delivered draft, instead of computing a shadow-mode verdict nobody acted on — gave the hedging logic real per-fact confidence to work with on the path that actually reaches a principal. S2 is the one honest holdout: the flip gave it a real, enforced ~90s word budget on the primary path (closing that half outright), but BriefComposer structures briefs by the older fixed THE_DAY/WORLD/RELATIONS/HOLDING categories, not the "setup counts → top-3 ranked signals" narrative shape this story's evidence has named since Phase 2 — that specific structure is still confined to the rarely-hit fallback text builder, and this pass didn't touch it. Building the flip also surfaced and fixed a real, independent, pre-existing bug unrelated to E1 itself: EditorService.auto_lock_pending() read BriefDraft fields (last_updated_at/created_at) that don't exist on the real contract, so the T-30 auto-lock sweep never actually fired in production — only a test's hand-written fake draft (which happened to define those nonexistent fields) made it look like it worked.

Extracting rank_top_signals() out of _build_speech_text into eva_domain so build_cue_cards() could call the identical function wasn't just S1's fix — it's also what made S2's already-heard demotion and S6's world_signal/drift card types possible, since both needed a card that traceably corresponds to something the voice brief actually said. Every one of E2's 9 stories was touched this pass (unusual breadth for a single epic pass this session); 7 reached DONE. The 2 that stayed PARTIAL were stopped for named, external reasons rather than scope-narrowed silently: S6's pattern card type needs EvaluatorService to expose an enumerable "current scenarios" store, which is E6-scoped work, not E2's, and legacy-surface consolidation (MorningBriefWidget/AlertBanner/DraftReviewScreen unifying into the new grammar) was correctly judged too large a redesign to absorb un-asked; S9's WCAG/contrast claim was left open specifically because no accessibility-audit tooling was run — adding Semantics labels is real progress but isn't the same thing as verifying compliance, and the audit says so rather than rounding up. A real side effect: wiring CorrespondentAgent.list_draft_replies_for_principal() for S6's draft card type gave E5's queue_for_principal() its first real external caller, a gap finding #7 named explicitly (“exposed via no route or MCP tool anywhere”) — though the queue is now reachable via cue-cards only, not via a dedicated E5 route, so E5's own verdict is unaffected.

Unlike E2 (blocked 2/9 on E6/accessibility-audit dependencies) or E1 (blocked on the Flutter repo's existence and Integrity Gate v2), none of E3's 5 gaps needed anything outside this pass's control: S1 needed one new read-only route over data that already existed (LivingDraftManager); S2 needed one Citation object built from fields the event envelope already carried, in the one automatic write path, plus not dropping a field in one response dict; S3 needed one shared helper called from three already-existing consumers; S4 needed one route that skips a keyword check plus one floating button; S5 needed one early-return guard checked in two places instead of one place with a spoofable parameter. None of these required new subsystems, new external services, or product decisions — which is also why this pass could close all 5 without narrowing any of them, unlike every prior "complete this epic" pass this session. One genuine design tension surfaced and was resolved conservatively: S5's fix could have generalized memo.py's per-section PRIVILEGED/MNPI voice interception to every brief type, but an existing, deliberately-scoped, currently-passing test (test_non_memo_brief_does_not_intercept_privileged_section) explicitly documents that as E8-S3's memo-specific behavior, not a general rule — so S5 was closed via a separate, additive whole-draft-scope check instead of touching that test's protected behavior.

PostMeetingDebriefService.create_debrief() (Phase 3) was real but fired synchronously end-to-end with nothing in between "audio arrives" and "commitments exist" — no capture surface (S1's gap), no way to hear or correct what was extracted before it became permanent (S2's gap), no gate requiring explicit confirmation before it committed (S3's gap), and no way to back out (S4's gap). Introducing exactly one new concept — a PENDING/CONFIRMED/CANCELLED DebriefCapture sitting between transcription and create_debrief() — closed all 4 simultaneously, the same shape finding #23 described for E3 (S1's rank_top_signals extraction) and finding #22 for E2 (S1's shared-ranking refactor): asking to complete an epic entirely surfaces these load-bearing single fixes more reliably than asking for one story at a time, because the dependency between stories is invisible until you're forced to look at all of them together. One honest limit disclosed rather than papered over: S4's "mandatory read-back" is enforced structurally (confirm requires a capture that only exists after the capture step) rather than by literally proving a client played the read-back audio — the latter is not something a backend can verify, and the audit says so instead of overclaiming enforcement that doesn't exist.

S1's first design used sender_tier as the CoVe verifier's independent signal — tracing it through select_action()'s existing branches showed every sender_tier this verifier would flag (board/regulatory/legal/exec) already triggers ESCALATE directly, making the check permanently unreachable dead code before it shipped. Caught by writing the test first and watching it fail to distinguish behavior, not by review. Rebuilt around deal-vocabulary-in-subject instead — genuinely independent of the existing branches, verified by tracing the same reachability question through to a passing, meaningful test. S6 could have reimplemented DKIM/SPF crypto+DNS verification directly (a security-sensitive judgment call this pass made deliberately conservatively, consistent with the prior audit's own "no unreviewed crypto dependency" caution) — instead it trusts the receiving mail provider's own Authentication-Results header, the same architecture virtually every production email security system uses, closing the story without adding an unreviewed dependency. S7's fix (principal_initiated) only became reachable in practice because S4's dictation flow exists to set the flag unconditionally — a cross-story dependency discovered by building S4 after S7's design was already drafted, requiring no rework only because S7 was designed as an additive permission (a flag that widens what's allowed) rather than a replacement of the existing draftable-actions check.

S1's confirmed-fixed 4h-crawl regression (finding #6) meant this story's actual remaining work was building a genuinely separate fast path, not a bug fix. S4's real finding wasn't "the queue needs a consumer" — it was that no concurrent/cancellable task concept existed anywhere in the voice-synthesis layer at all, so a P0 arriving mid-render of a lower-priority brief had no way to actually jump ahead of it; fixed with a real `asyncio.Task` + `.cancel()`, proven with a slow fake adapter genuinely blocked and cancelled, not a timing assumption. Two bugs were found only as a side effect of implementing something else: `SupabaseSentinelStore` was missing `suppression_counts()` entirely (would 500 in production, found while wiring S9's principal-facing rollup) and `AlertStatus.ACKNOWLEDGED` had existed as a dead enum member since before this session (found while designing S10's demotion sweep, which needed a real ack concept to exclude acknowledged alerts from demotion). S12 closed the exact class-collision finding #3 named in the very first audit pass of this session — evaluator.py's directive `ScenarioAnalysis` colliding with relevance.py's correct advisory-only one — by renaming and rewriting rather than deleting either, since both serve genuinely different real call sites (per-event scoring vs. free-text scenario description).

`test_relational_graph_detects_tone_driven_drift` existed specifically to prove tone alone (cadence_score=0, perfectly on cadence) could fire drift with `tone_drift=0.85` — exactly the "implemented backwards" behavior the spec forbids, and exactly what finding #3's original audit pass flagged. There was no way to fix S2 without that specific test starting to fail; the correct response was recognizing the test encoded the bug, not treating a red test as a regression to avoid. It was replaced with a test asserting the opposite (tone alone never drifts on normal cadence) plus a new test proving tone still genuinely corroborates an already-elevated signal — the fix is more restrictive than the old behavior, not merely different. S3 and S5 both compose directly on top of S2's `tone_corroborates` boolean (S3 feeds it a real signal instead of a caller-supplied scalar; S5 forces it permanently off for counsel relationships) — a design that would not have been available had S2 stayed a `max()` calculation with no clean corroboration/no-corroboration branch to hook into. S4 deliberately kept a new corroboration method separate from the existing `pinned_ghosts()` rather than modifying it in place, the same non-breaking-additive-surface pattern E6-S9's rollup and E6-S6's health report both used — proving out as a repeatable convention across epics, not a one-off choice.

Phase 4's note said E8-S1's real ask — a shared brief-variant composition path — "still doesn't exist" and framed closing it as a re-architecture out of proportion for a P3 pass. Direct re-reading (not trusting the note) found that by Phase 15, a memo already flowed through the exact same generic open/add_section/deliver/to_ssml machinery every other non-tier-1 brief type uses — the prerequisite had been satisfied as a side effect of unrelated work in later phases, never re-checked against E8 specifically because E8 was never revisited. What remained wasn't architectural at all: `AddSectionRequest` (the actual HTTP contract a Flutter client uses) simply had no `zone` field, so S3's already-correct backend interception logic was unreachable end-to-end for a reason no amount of re-reading `voice.py` in isolation would surface — it required reading the request/response contract at the boundary. This is the same class of finding as finding #4 (Flutter wired to the wrong JSON contract) but inverted: here the backend was right and the HTTP surface silently dropped a field, rather than the frontend expecting fields the backend never sent. A second, independently-found bug (GET /brief/{draft_id}/audio's on-demand fallback synthesizing the wrong brief's content for any non-tier-1 draft with no manifest) would have caused a real, silent, hard-to-diagnose production bug — playing a memo out loud would have played someone's morning brief instead — had this pass not read that route's fallback branch specifically while building the memo player.

E9-S2's evidence text explicitly named “the MCP tool path the agent actually uses still strips citations” as the blocking gap. Reading `_handle_recall_facts` directly found a comment reading “FR-E3-S2” sitting on the exact line that returns citations — the fix had already landed as part of closing E3-S2, in a pass that had no reason to think of itself as touching E9 at all, and no later pass ever re-checked E9's own verdict against it. This is the same stale-audit-note pattern finding #19 documented for E9-S4 (fixed by an unrelated E15-S3 consumer), now recurring a second time within the same epic. Separately, `RecoveryCoordinator.restore()` (compliance/recovery.py) had a complete, tested snapshot/restore/replay_since implementation with zero callers anywhere in the codebase before this pass — the exact graveyard shape finding #2 first named (a real mechanism, fully built, simply never wired to anything that invokes it). Rather than exposing it as a bare MCP tool reachable by any principal — wrong for a destructive DR action — it was wired as a new caller inside the pre-existing password-gated `/admin` console, matching the console's own established pattern for every other irreversible action it already gates. The through-line across all three: closing a P0 epic correctly required distrusting every existing verdict enough to re-derive it from current code, not just from the story's own prior note.

Every epic closed earlier this session (E6-E9) turned out to be substantially further along than its own audit note claimed once the real code was read directly. E10 inverted that: only S2 (low-confidence quarantine) was actually DONE; S1/S3/S4/S5 really were untouched, exactly as documented. But even here, re-reading paid off in a different way — the prior gap note for S1 said "sensitivity-category concept (board/investor/counsel/MNPI/family) was out of scope," a reasonable paraphrase, but pulling the literal EVA_Sprints.xlsx row text showed the acceptance criteria names five specific categories with exact spelled-out labels (counsel-and-legal, MNPI-touching, family-and-personal) that don't map cleanly onto the existing DataZone enum's three non-general values — a naive implementation reusing DataZone (the pattern this session used repeatedly for E7-S5's counsel gating) would have silently narrowed the story's actual scope. Reading the sprint sheet directly before designing, rather than trusting a summary of it, is what caught this. The same discipline applied to S3 ("exceeds a configured depth") surfaced that the story explicitly wants a *configurable* threshold, not a hardcoded one — missed entirely by a paraphrase that only said "brief-priority item when deep." Lesson for future epics: even a story correctly marked NOT STARTED can have its true acceptance criteria under-specified by an audit's own prose summary; the sprint sheet itself is the ground truth, not the note describing it.

ROADMAP.md's own Phase 0.4 entry named this explicitly: an earlier pass (DEV-NOTES.md correction M) had deliberately ripped zone-based access control out of PolicyGate because zone was never an attested claim (self-declared per tool call, confirmed via a direct grep showing zero authentication of it anywhere) — "enforcing" it was a false guarantee, not real security. That directly regresses E11's own premise ("air-gap" privileged/MNPI data), and the roadmap flagged two live paths forward — formally accept the descope, or build real zone attestation and restore the check — as a decision needing to be made, not a bug needing a fix. Writing code first and picking a direction implicitly would have been exactly the kind of unilateral security-posture call the session's own operating rules exist to prevent; asked directly via AskUserQuestion instead. Once the decision landed (formally descope), the remaining work sorted cleanly into two buckets: S2/S4 are the crux of the decision itself and closed with zero code (writing a "solution" for either would have quietly re-introduced the exact unattested-zone theater the decision just rejected); S1/S3/S5 turned out to be genuinely separate concerns — encrypting opaque audio blobs, exposing an already-built audit-query service over HTTP, and surfacing an already-computed routing label — that had simply never been distinguished from the zone-enforcement question in the original audit's framing. Separating "what this decision resolves" from "what was merely sitting next to it, unbuilt" is what let 3 of 5 stories close with real code despite the epic's central mechanism being permanently retired.

E12-S2 asks for logic keyed to "T-15" and "T-0," but morning briefs in this codebase are not rendered by middleware code running at a precise clock offset — scheduler._morning_brief_single only enqueues a job; an external LLM agent (OpenClaw) picks it up on its own heartbeat and calls eva_open_draft/eva_submit_brief_plan/eva_deliver_draft itself, at whatever wall-clock moment its heartbeat happens to land. There is no "T-15" instant the middleware could poll for even in principle. Building a naive T-15 clock-check job against this architecture would have been busywork that could never actually fire at the right moment. The honest equivalent: tie auto-injection to the real, observable condition the PRD language is actually gesturing at — "is a P0 event arriving while today's morning draft is still being finalized" — which holds regardless of when the agent's heartbeat happens to start assembling. E12-S3 hit the same shape of problem from the opposite direction: the literal ask ("routes via the real-time alert path (priority queue at the Renderer)") sounded like it demanded a working priority-queue consumer, but re-reading found the real-time render already happens synchronously elsewhere (sub-1s SLA-measured) — the queue push was vestigial. Building a queue-worker to satisfy the letter of the ask would have added latency and defeated the point; the honest fix was recognizing the literal ask was already met, and giving the unconsumed queue a real, narrower job (reliability retry) it didn't already have. Both cases share a lesson distinct from this session's usual "stale audit note" pattern: sometimes the sprint-sheet language itself describes a mechanism that doesn't map cleanly onto the actual system, and closing the story honestly means identifying the real underlying guarantee the language is reaching for, not force-fitting a literal implementation that would be theater, redundant, or both.

E13-S1 asks for suppression when "a contact has active HR-tagged correspondence" — the natural reading is an ordinary contact (a colleague, a report) who happens to have an HR matter open about them, not a contact who is permanently filed under some special "HR zone." But evaluate_drift's gate read `is_hr = scope.zone == HR or record.zone == HR; if is_hr and is_hr_thread_open(...)` — and every single test exercising HR-thread suppression, without exception, constructed its scope with zone=DataZone.HR. The tests passed, the coverage looked complete, and the prior audit pass's PARTIAL verdict cited only reachability gaps, never questioning whether the suppression logic itself was correct — because from the tests' vantage point, it always was. Reading the acceptance criteria's exact wording against the code's exact condition (not against what the tests exercised) is what surfaced it: for a GENERAL-zone contact — the realistic case — `is_hr` was always False, so `is_hr_thread_open()` was never even called, and the whole mechanism was dead on arrival for anyone not literally zone-tagged HR. This is a different failure mode than this session's recurring "stale audit note" pattern (a real fix elsewhere that a later pass never re-checked): here the code was wrong from the moment it shipped, and a self-consistent test suite that only ever tested one branch of a two-branch condition made it look verified. The fix — checking is_hr_thread_open() unconditionally — was a one-line change once found; finding it required distrusting green tests, not just stale prose.

E14-S1's "never pulls" clause survived two prior passes unresolved because each pass looked at the pull site (_cartographer_crawl's calibration_service.snapshot() call) in isolation and asked "how do we stop this from firing," not "where would the data come from instead." The answer was already sitting in the event: CalibrationService._commit() has published the full interest_tags list on every CALIBRATION_UPDATED event since the Phase 3 pass that built S3's fast-track trigger — CalibrationConsumer.process() was already receiving that payload on every single calibration change, but only ever read event.payload['reason'] to call schedule_push(), discarding the tag data itself. Once noticed, the fix was small: a dict cache, written from the payload already in hand, read by the crawl job instead of calling back into the service. No new push mechanism needed building; an existing one just needed its data actually consumed. Separately, S2's "P0 topic" had no literal match anywhere in the codebase by that name — the honest resolution wasn't inventing a new concept but recognizing CorrespondentAgent's own docstring had already named its ESCALATE action step "P0 alert to principal" long before this epic existed, the same "identify the real underlying guarantee the language is reaching for" move finding #32 named for E12's T-15/priority-queue language, encountered here a third time on the same session's fourth calibration-related epic.

E15-S1's Phase 1 evidence named six specific gaps by exact enum value: Correspondent's ACTION_LADDER_DECISION/THREAD_ROUTED/ALWAYS_ROUTE_FIRED, Arbiter's DRIFT_EVENT_FIRED/CONFIDANT_FLAG_FIRED, Renderer's BRIEF_PLAYBACK_PROGRESS. Between that finding being written and this pass, this same session rewrote large parts of correspondent.py (E5's CoVe/always-route work, E14's calibration trigger), relationships.py and confidant.py (E7's Golden Baseline wiring, E13's HR-thread fix, E14's audit_sink-adjacent scheduler work), and brief_routes.py (E2's cue-card routes, E12's provenance routes) — any of which could plausibly have added the missing audit calls as a side effect, the way E7's SupabaseRelationshipStore rewrite incidentally fixed E13-S1's evidence base before E13 itself was ever worked. A fresh repo-wide grep for `action=AuditAction.` on all six, run before writing any code, found zero hits on every one — the finding was still exactly true, unimproved by five epics' worth of adjacent work, because none of that work had reason to add audit logging as a side effect the way store-delegation rewrites do. The lesson this adds to findings #16/#17/#33's running list: re-verification isn't just for catching a finding that's gone STALE (already fixed elsewhere) — sometimes the honest re-check confirms nothing has changed, and that confirmation is itself the work, not a shortcut past it. Distinct from finding #34's "the fix was already half-built and unconnected" shape: here, nothing was half-built; six real gaps needed six real fixes, discovered fresh in this pass rather than inherited free from someone else's.

E14-S2 wired wiring.py to post-hoc attach calibration_service onto whatever calendar_orchestrator was in play, exactly mirroring the tone_engine/crawler/audit_sink pattern SupabaseCalendarStore already exposed for other collaborators — except calibration_service itself had no matching property on that class. Setting `calendar_orchestrator.calibration_service = x` against a SupabaseCalendarStore instance didn't raise (Python doesn't complain about setting a bare, undeclared instance attribute), it just created a new attribute the internal engine's propose_meeting never looks at, since propose_meeting checks self.calibration_service on the wrapped CalendarOrchestrator, not on the wrapper. Every E14 test constructed a bare CalendarOrchestrator directly (the in-memory dev/test path, where the pass-through gap doesn't exist because there's no wrapper) — none exercised the Supabase-backed path this exact scenario needed to catch it, so the feature was broken in every real deployment from the moment E14 shipped and stayed that way through the entirety of E15's audit-logging pass, discovered only because E16 happened to be deep in the same file for an unrelated reason (S9's timezone persistence). The fix — a three-line property/setter pair, the same shape already sitting three lines above it for tone_engine — took seconds once found; finding it took working in calendar_store.py for a different story and noticing the missing symmetry, not a targeted search for this specific class of bug.

E17-S8's source_event_id dedup (return the existing open commitment instead of minting a duplicate when create() is called twice with the same source_event_id) is the right model for a genuinely 1:1 origin — one email thread, one calendar event, one commitment. The first wiring attempt applied it to post_meeting.py's debrief action-item extraction too, using the meeting's own calendar_event_id as every extracted action item's source_event_id — but one meeting transcript routinely produces several distinct action items ("I'll send the deck," "Sarah will follow up with the vendor"), all sharing that same calendar_event_id. The second create() call didn't mint a second commitment; it silently returned the first one, collapsing every action item from a meeting into one. test_post_meeting.py's existing test_create_debrief_creates_real_commitments_in_tracker (asserting exactly 2 commitments from a 2-action-item transcript) caught this immediately on the first full-suite run — asserting 1 == 2. The fix was to not set source_event_id at that call site at all, rather than adding a special case to the dedup logic itself: S8's model is 1:1, debrief extraction is 1:many, and the honest resolution is recognizing the two don't compose, not forcing them to. This is a different failure mode from findings #33/#35's "stale audit note" or "code wrong since it shipped" shapes — here the new code and the new test were both written in the same session, by the same pass, and the test suite (not a targeted second look) is what surfaced the interaction the design review missed.

ScribeService (eva_domain/keeper/scribe.py) had a complete MCP tool surface (eva_scribe_create/update_section/finalize/archive/delete/get/list/review) but zero REST routes — every other Keeper concept with a principal-facing story (commitments, drafts) got REST routes somewhere in a prior phase; Scribe never did, because until E18 none of its stories explicitly required a human, as opposed to an OpenClaw agent, to act on a Scribe document. E18-S3 ("uncited claims are flagged for principal review before send") and E18-S6 ("the Scribe pauses and requires explicit principal confirmation per draft") changed that: both are asks about what a principal does, not what an agent does, and an MCP-tool-only surface has no principal on the other end of it — OpenClaw is the only caller. This wasn't a bug that shipped and went unnoticed (the MCP surface worked correctly the whole time, per E18-S2's prior DONE verdict) — it was a capability whose only reachable caller was structurally the wrong one for two of this epic's seven stories. Closing it meant building the first REST routes Scribe has ever had (GET/POST /keeper/scribe/documents and friends) before the Flutter screen consuming S3/S6's confirm gates could exist at all — the same shape as finding #2's "graveyard of features with zero production callers," except here the caller that existed (OpenClaw via MCP) was real and correct, just categorically unable to be the principal the story was written about.

SubscriptionRecord/PlanTier (built in an earlier phase) modeled subscription state as a single trial/active/downgraded tier — sufficient for S1's demo clock and S2's credential revocation, both of which are whole-account concerns. But S3/S4/S6/S7's literal wording ("drops the Cartographer or Arbiter") and S5/S8's per-pillar retention/resume language describe two independently droppable pillars, not one kill switch — a downgrade that always drops both together cannot represent "Cartographer dropped, Arbiter still active," a state four of the remaining six stories require to even be tested. Rather than force-fitting the existing whole-account model (which would have made S3/S4/S6/S7's tests indistinguishable from S1/S2's), SubscriptionRecord gained real cartographer_active/arbiter_active fields and is_pillar_entitled(pillar), with drop_pillar()/reactivate_pillar() as the new per-pillar transition methods — reusing the whole-account downgrade()/reactivate() for the day-90 case (both flags flip together) and the new pair for independent pillar drops. One primitive, is_pillar_entitled(), is what every write route, both Redis Streams consumers, and both scheduled background jobs check — the same "one shared entitlement primitive reused everywhere" shape E18's event_bus/audit_sink/mcp_server wiring used to close S1/S7 together, applied here to close four stories (S3/S4/S6/S7) at once instead of one at a time.

voice_latency_sla_ms (default 4000ms, config.py:87-90) measures server-side TTS synthesis wall-clock time — the interval EdgeTTSAdapter.synthesize() spends on a real network call to Microsoft's edge service. E1-S1's literal ask ("audio begins within 200ms from edge cache" at tap) describes a categorically different measurement: tap-to-first-audio-byte from a pre-warmed, edge-served cache. Blindly lowering the SLA default toward 200ms would have made sla_breached fire on nearly every real synthesis call (EdgeTTS routinely takes over a second for real speech) without moving a single line of the actual tap-to-play path closer to the target — noise dressed as progress. Digging further surfaced a second, harder truth: no CDN/edge-cache provider exists anywhere in this codebase (exhaustive grep for cloudfront/cdn/edge_cache/signed_url: zero matches), and building one needs real external cloud infra/credentials outside any pass's reach without the user explicitly provisioning it. Surfaced both findings to the user via AskUserQuestion before writing any code, got explicit sign-off to build only the achievable subset (T-30 pre-synth for the morning/EOD path that never had it, despite pre-meeting briefs getting the equivalent fix in an earlier phase) and flag CDN provisioning as deferred infra rather than quietly declaring the story closer to done than it is. Same underlying discipline as finding #10's "entry point built, zero production callers" and finding #15's wiring-gap pattern — a plausible-sounding fix (change a config default) that doesn't touch the actual mechanism the story depends on is exactly the kind of shortcut this audit exists to catch, whether it's found in the codebase or almost written into it.

E6-S12 (an earlier phase) touched the exact same evaluator.py/ScenarioAnalysis area E2-S6's PATTERN gap depends on, and explicitly declined to build a persistent "current scenarios" store, documenting that as deliberate E6-scoped future work (ROADMAP.md's Phase 13 entry, line 380 at the time). A fresh research pass confirmed that decision was still accurate against current code — nothing built across E6, E7, E12, E15, or E19 had changed it. Rather than unilaterally reversing a different phase's documented call, this was surfaced to the user via AskUserQuestion with the real tradeoff named (build the store now vs. leave PARTIAL); the user chose to build. What "the store" turned out to need was smaller than the original gap note implied: not a new store class or app.state entry, just two new dataclass fields (scenario_id/evaluated_at) and one bounded self-managed dict inside EvaluatorService itself — the same shape SentinelAlertManager already uses for its own per-principal state. The Flutter side needed nothing at all: CueCardsScreen's icon/label maps already had a 'pattern' entry from when the enum was first declared, waiting for real data that had never arrived. Net: a decision that looked like it required re-litigating another epic's scope turned out to be a same-pass, backend-only fix once actually scoped — but the discipline of asking first, rather than assuming the old gap note undersold the effort, was what made that assessment trustworthy rather than a guess.

E2-S9's "speed control without pitch distortion" requirement looked like it might need a setPitch() call to be added — instead, reading just_audio 0.9.46's Android (AudioPlayer.java's PlaybackParameters(speed, pitch)) and iOS (UriAudioSource.m's AVAudioTimePitchAlgorithmTimeDomain) implementations directly showed both platforms already decouple speed from pitch by construction, and the app never calls setPitch() at all — pitch stays at its unity default regardless of setSpeed(). Zero code needed; the honest close was documenting why, not adding an unnecessary call. The WCAG requirement went the opposite direction: "contrast unaudited" from the prior pass sounded like a documentation gap, but computing actual relative-luminance contrast ratios from EvaColors' real hex values against the backgrounds text actually renders on found a genuine, quantified failure (EvaColors.rule: 2.0-2.65:1, needs 4.5:1) that was also systemic — it was EvaText.mono()'s own default color, the style nearly every label in the app uses, not an isolated cue-card styling choice. Both findings only surfaced because the research went to primary sources (package source code, computed contrast math) instead of trusting the surface-level claim ("just_audio has setSpeed, so pitch might shift" / "no audit tooling ran, so contrast is unknown") — the same discipline finding #40 named for the SLA-config mixup, applied twice more in the same story with opposite outcomes: one gap closed by proving it was never real, the other closed by proving it was real and then fixing the actual mechanism.

Finding #16 (Phase 2) had already noted E1-S2 stayed PARTIAL because "the setup/top-3-cross-domain-ranked-signals narrative... still exists only in the rarely-hit fallback builder" — accurate as far as it went, but reading voice.py's to_ssml() directly (the function every real synthesis call actually invokes, not compose_sections()'s persisted output) found something the evidence never named: to_ssml() has no closing line at all, and compose()'s opener/closer wrapper that would have provided one was test-only, never imported by production code. The literal fix wasn't as simple as copying the fallback builder's shape over, though: that builder's "top 3 signals" is content-selection — only 3 items get spoken, everything else is silently dropped — which would violate Integrity Gate v2's R2 rule that every accepted P0/P1 alert and due commitment must appear in the delivered brief. Porting the fallback's shape naively would have quietly regressed a guarantee a separate, earlier piece of this same system depends on. The resolution: read "surfaces three priority items" as a preview framing, not a content cap — a short, bounded top-3 spotlight wraps the full, unchanged categorized sections rather than replacing them. A first implementation attempt used the full rendered sentences for the preview and only caught its own budget-blowing failure mode via the existing test suite's deliberately-verbose fixture (test_over_budget_plan_drops_lowest_salience_items_first's 60-word summaries) — a concrete instance of this session's "run tests immediately, let a failure catch a design flaw before it ships" discipline working as intended, not just documentation after the fact.

User decided the zoning-as-architecture half (storage partitioning, KMS key derivation, audit-channel tagging, Cartographer private-surface routing, cross-zone backend switching) wasn't needed, but the compliance behaviors reading the same DataZone field — E3-S5's voice refusal, E5-S7's MNPI ladder, E13's HR/MNPI/PRIVILEGED masking, E18-S5/S6's privileged-doc/confirm/outline gates — had to keep working exactly as before. Reading relationship_store.py's initialize() found the actual partitioning mechanism was a single property (PrincipalScope.storage_namespace) and a handful of zone_namespace()-style key-builder functions, not the field itself scattered everywhere — fixing those few functions to drop the zone segment cascaded correctness to every in-memory-backed store automatically, with zero changes needed to the ~9 files whose compliance logic reads .zone directly to decide masking/refusal. This confirmed a design choice made before writing any code (keep the enum, degenerate the infra consumers, versus fully replacing DataZone with independent booleans everywhere) was the right one: same end-user compliance behavior either way, but the chosen approach touched roughly a third as many files. One genuine, disclosed side-effect survived: since the scheduler no longer varies its scan scope per zone (correctly — storage no longer partitions by zone, so one scan already reaches every record), fired relationship-drift events' own .zone metadata field now always reads GENERAL, reflecting the scan's scope rather than the record's real tag — the masking decision itself still reads the record's preserved zone correctly and produces the right masked summary, only that one metadata field lost per-record fidelity. Also reversed, deliberately: E11-S1's audio encryption-at-rest, E11-S3's audit-channel separation, and E11-S5's private-surface alert routing — all real, tested Phase-18 features, now intentionally degenerated rather than silently left to bit-rot, with 29 pre-existing tests rewritten (not deleted) to assert the new reality.

Successive external audits (each independently re-running the full suite, ruff, and a dependency check) surfaced infrastructure and security defects in the layer beneath the stories — webhook authentication, event-bus reliability, the credential/OAuth lifecycle, and disaster-recovery restore. These were fixed in discrete rounds, with the full backend suite green (1,339 tests by the end) and ruff clean after every round. The story verdicts stayed 118 DONE / 1 PARTIAL / 2 NOT STARTED throughout precisely because the fixes changed HOW the existing DONE features are authenticated, transported, and persisted — not WHAT they do. Findings #46–60 record the substance. A recurring, honest pattern across the stream: several findings were shortcomings in a fix from the immediately preceding round (e.g. an allowlist made too broad, a retry counter keyed too coarsely), caught and corrected in the next round rather than defended — the audit loop working as intended.

GraphitiGraphMemoryStore wrote and dropped its local fact index under _episode_group(scope) (which replaces colons with underscores) but get_fact()/snapshot()/restore() read from the raw zone_namespace(scope) — different strings, so direct fact lookups returned nothing and snapshots came back empty even though writes succeeded. VoiceProfileManager.initialize() cached profiles under the raw principal_id while update_from_correction/list_versions/rollback keyed by scope.storage_namespace — so after a Supabase reload the version history read empty and the next correction reused version 1, colliding with migration 038's (principal_id, version) unique constraint. Both fixed by keying reads and writes identically; the same class as the de-zone storage_namespace collapse.

SupabaseCredentialBroker.register() never wrote refresh_token, and the OAuth callback PATCHed it onto a row that did not exist yet (a no-op on first connect) — so first-connect credentials became unrefreshable once the access token expired; restore() dropped it too. The Slack callback stored account_id=team.id while /oauth/status and the connector tools looked under "primary", so Slack always appeared disconnected. OAuth state was ctx.principal_id verbatim and unsigned, so a callback's authorization could be bound to any attacker-chosen principal. Fixed: refresh_token added to CredentialSecret and persisted in register()/restore() — omitted from the upsert when None so a refresh-cycle re-register preserves the stored value rather than nulling it; Slack account_id normalized to "primary" (team id moved to the webhook registry, not the credential lookup key); and OAuth state HMAC-signed and verified on callback, the same {payload}.{sig16} pattern later reused for webhook bindings (#50).

New GatewayAuthMiddleware requires x-eva-gateway-token to equal EVA_GATEWAY_SHARED_SECRET (constant-time compare) for every request outside a small public allowlist, covering both HTTP and WebSocket scopes, fail-open in dev, and flagged in production_readiness_issues(). Key issuance (/keys), GDPR erasure (/webhooks/forget), the nabh LLM proxy, and every principal-scoped route moved behind it. Additionally: forget was restricted to self-erasure unless the caller holds a compliance (counsel) role; the nabh proxy stopped reading os.getenv at import (reads settings per request) so it is no longer a blanket open relay spending the server's API key; and EOD audio picked up the same device-attestation gate /brief/{draft_id}/audio already enforced. The allowlist was deliberately over-corrected once and re-tightened in the next round: an initial /oauth/* entry exposed /authorize_url and /status (which read/sign the principal from the header) — narrowed to /oauth/*/callback only, since only the provider callbacks are hit externally.

PillarConsumer._handle dead-lettered on the first failure and never acked the original — contradicting its own _MAX_DELIVERIES = 3 docstring — so the pending entry was reclaimed and reprocessed indefinitely, writing a duplicate dead-letter each time; now it leaves the message unacked to be retried up to the budget, then dead-letters once AND acks. The retry counter was keyed by message_id alone, but Redis stream ids repeat per principal stream, so one principal's 1-0 could spend another's budget — now keyed by (stream, message_id). Consumers snapshotted the principal list at startup; the loop now drains the shared live list each pass (extracted as _drain_once for deterministic testing) and ensures the consumer group on first sight, with the admin create route appending the new principal. And RedisStreamsEventBus.replay used an inclusive XRANGE min=start while the in-memory bus was exclusive-after-start, so replay_since double-counted the event sitting exactly on the recovery-point boundary — made exclusive ((start) to match.

New HMAC-signed bindings (webhook_binding.py, the same signing pattern as OAuth state) are set as the Google channel token and the M365 clientState at watch-registration — a new register_watch() on the connectors that also records the provider's channel/subscription id in a resource→principal registry (webhook_subscription_store.py + migration 041, wired GDPR-erasable). The webhook routes now derive the principal from the verified provider signal — Google channel token, M365 clientState, Slack signing-secret HMAC plus a team→principal mapping recorded at OAuth connect — and never from the header, rejecting outright when it cannot be established. A dev fail-open remains only when no secret is configured; production always has jwt_secret, so it is always strict there. A follow-up audit hardened strict mode further to require BOTH a valid signed binding AND a registry match (so a leaked or guessed resource id alone can no longer attribute an event), and corrected the Supabase upsert conflict targets per identifier type with matching unique indexes. Because the routes now self-authenticate, the three provider-webhook paths are back in the gateway public allowlist (they are reached by providers directly); /webhooks/forget stays gated.

fakeredis (added to the dev dependency group) drives RedisStreamsEventBus's actual Redis calls — publish/read/ack, idempotency, and the exclusive-replay boundary (#49) — with reclaim skipped-with-reason if the fake lacks XAUTOCLAIM rather than silently dropped. GraphitiGraphMemoryStore gained an injectable-client seam so its write/get/snapshot/restore run against a fake async client, proving restore() now replays each fact as an episode into the graph backend, not only into the local index. Disclosed rather than glossed: the provider watch-registration HTTP (register_watch) is exercised only against mocked httpx, and true live Neo4j/Graphiti and a live Redis server still cannot run in this environment — the same standing caveat the S3/Vault encryption paths already carry.

A complete callability test drove all 85 registered tools through OpenClaw's own live MCP endpoint and API key. Every tool dispatched — but calling a write tool with {} (or a blank/whitespace required value) returned success and created a junk row, because the handlers read arguments with .get(...) defaults and no layer validated the schema's required list first: an empty eva_create_commitment persisted a blank commitment, eva_open_draft an empty draft, eva_scribe_create an “Untitled” document. Dispatch (EVA_MCP/src/eva_mcp/registry/dispatch.py, helper in registry/helpers.py) now rejects a tools/call whose arguments omit — or leave None/blank — any top-level inputSchema.required field, returning JSON-RPC -32602 (HTTP 400) after principal auth but before the policy gate, so a malformed call has zero side effect and writes no audit row. The check is deliberately stricter than JSON-Schema presence (whitespace-only counts as missing — that blank case was the junk source). Full backend suite green at 1,343 (24 existing missing-field tests re-pointed at the dispatch rejection, 5 new enforcement tests, 3 integrity tests corrected for the now-required field), ruff clean; deployed to the VPS and live-verified through OpenClaw. Verdicts unchanged — this hardens input validation at the tool boundary, not what any tool does.

The Slack Events route verified signatures only when SLACK_SIGNING_SECRET was configured; unset meant no verification, and _scope_or_reject then fell back to the spoofable x-eva-principal-id header (or "demo"). production_readiness_issues() never checked the secret and the prod compose never passed it, so an otherwise-complete production deploy stayed “ready” while accepting header-attributed unsigned events. SLACK_SIGNING_SECRET is now a production readiness requirement when Slack is configured (config.py:217); /webhooks/slack (webhooks.py) rejects unsigned requests in production and is always strict there — an unresolved principal is a hard 401, never a header fallback. docker-compose.prod.yml now plumbs the secret. The readiness requirement is made fail-closed by #54.

GatewayAuthMiddleware allows every request when EVA_GATEWAY_SHARED_SECRET is unset (the intentional dev convention), and production_readiness_issues() was consulted only inside the /health/ready handler (main.py:131) — the app served regardless. So a production deploy without the secret answered /api/v1/keys 200 for a spoofed x-eva-principal-id while readiness returned 503. Root fix: create_app() now raises (EVA_Bureau/src/eva_bureau/main.py) whenever production readiness is unmet, so a missing gateway secret / JWT / Slack-signing / backend refuses to boot rather than run fail-open — fail-closed at startup, not merely reported. Staging keeps the deliberate fail-open (OpenClaw reaches the middleware directly, no gateway in front). docker-compose.prod.yml now hard-requires the secret (${EVA_GATEWAY_SHARED_SECRET:?}).

oauth_routes.py's _error_page interpolated the provider-supplied error straight into the page, so /api/v1/oauth/google/callback?error=<script>…</script> returned the script verbatim (the callbacks are public by design). The message is now passed through html.escape. Live-verified on the VPS: the crafted callback returns <script> entities with no raw tag.

admin_routes.py rendered stored display_name, email, key labels, ids, and error text directly into HTML. It now HTML-escapes every interpolated value (stored XSS closed), compares the admin password with hmac.compare_digest (constant-time), throttles login per client IP (5 attempts / 5 min → 429), and embeds a per-session synchroniser CSRF token in every state-changing form, required on the matching POST — defence in depth behind the already-present SameSite=Lax session cookie. Admin-gated, so lower exploitability, but real.

/api/v1/auth/dev-token (router.py) issued an attestation JWT for an arbitrary principal_id with no identity proof, refusing only when is_production — so on the staging VPS (EVA_ENV=staging, gateway-allowlisted) it was a free any-principal mint. It is now disabled by default everywhere and honoured only when EVA_ENABLE_DEV_TOKEN=true in a non-production env (config.py). Live-verified: ?principal_id=victim now returns 403 on staging. (It grants attestation only — MCP tool calls still require x-eva-api-key — but an any-principal mint had no business being reachable.)

SupabaseRestClient appends caller-built query strings to the URL unencoded (supabase_client.py), and stores interpolate principal_id into them (e.g. principal_id=eq.{id}), while PrincipalScope enforced only min_length=1. A principal id carrying PostgREST metacharacters (, & ( )) could therefore rewrite the filter. PrincipalScope.principal_id is now constrained to ^[A-Za-z0-9._-]+$ at its single validation point (eva-contracts/principal.py), which neutralises the injection class regardless of how the id arrives — and, since #54, a spoofed id also can't ride a fail-open gateway in production.

User-registered monitored-source URLs (eva_register_source) went unchecked into a server-side fetch (reporter.py) with follow_redirects=True — reachable at cloud metadata (169.254.169.254) and internal services. A new guard allows only public http(s): IP-literal and private/loopback/link-local/reserved/multicast targets are rejected at register and re-checked at fetch, with follow_redirects=False to remove the redirect-to-internal bypass; an unresolvable host is left to fail at fetch rather than hard-blocked (keeps the guard offline-testable, and DNS-rebinding is caught by the fetch-time re-check). Live-verified: registering http://169.254.169.254/… is refused with no side effect.

File-convert, STT, correspondent-dictation, and post-meeting-capture all did await file.read() (whole body) and only then checked the length. A shared bounded reader (EVA_Bureau/src/eva_bureau/uploads.py) now streams in fixed chunks and raises 413 the moment the cap is exceeded — never buffering more than the limit — wired into all four routes. Full security pass: backend suite 1,376 passed (33 new hardening tests), ruff clean, deployed to the VPS and live-verified (dev-token 403, OAuth escaped, SSRF blocked, MCP still authenticating the real principal). No story verdict changed — every fix hardens authentication / transport / input-validation, not what a feature does.

New migrations/042_integrity_gate_hardening.sql adds gate_calibration (per-principal trust_floor/max_items_per_section/max_connectors_per_section), originating_prompts, and plan_snapshots.job_prompt. EVA_MCP/src/eva_mcp/registry/integrity.py's _handle_submit_brief_plan now: (1) loads a GateThresholds row via gate_calibration_store and feeds it into planner_gate.evaluate(), instead of always the hardcoded module defaults every principal shared regardless of what they'd been calibrated to; (2) checks R5's prompt-echo rule against snapshot.job_prompt — the real prompt EVA_Bureau/src/eva_bureau/routes/chat_routes.py's new _capture_originating_prompt stashes at /chat time and eva_open_draft freezes into the snapshot — not the caller-supplied job_prompt submit argument, which a malicious or buggy caller could set to whatever text it wanted checked against (now advisory-only, documented as such in SubmitPlanArgs); (3) rejects a submit whose snapshot is older than plan_snapshot_ttl_seconds (default 900s) with STALE_SNAPSHOT, forcing a re-open rather than gating a plan against a referent universe that may no longer reflect reality. A fourth candidate fix — tightening VoiceDeliveryBridge.to_ssml() to refuse an unstamped-but-content-bearing tier-1 draft — was deliberately reverted: it broke two tests, because an unstamped draft with content is structurally indistinguishable from legitimate pre-existing states (older fixtures, non-gate flows), and every production gated draft is already stamped-or-empty via the pre-existing add_section block plus DefaultPlanner's auto-stamp — the tightening added no real guarantee while breaking real ones. 7 new tests (test_integrity_gate_hardening.py), full backend suite 1,397 passed, ruff clean. Live-verified on the VPS against a real principal: a genuine /chat message traced through to plan_snapshots.job_prompt; a gate_calibration row with max_items_per_section=1 flipped a real verdict's rules_fired to include R6_BOUNDS; a snapshot backdated 2 hours past the TTL was rejected with STALE_SNAPSHOT on resubmit. No story verdict changed — this hardens the gate's own inputs, not what it evaluates.

Finding #36 documented SupabaseCalendarStore missing a calibration_service pass-through, so a post-hoc-attached collaborator the wrapped CalendarOrchestrator checked internally was silently unreachable through the Supabase wrapper in every production deployment. The same shape existed a second time for a different method: reveal_privileged_meeting(), added to CalendarOrchestrator by Phase 23 for E16-S7, had no matching delegation on SupabaseCalendarStore — callable against the in-memory dev/test path, unreachable against the production-backed store. Added the delegation plus a parity test asserting the Supabase store's behavior matches the base orchestrator's. Deployed to the VPS. No story verdict changed — E16-S7 was already graded DONE against the orchestrator method that did exist; this closes the gap between that method and the store actually wired to production.

evaluate_drift's LookupError for an unknown relationship id propagated uncaught out of arbiter_routes.py's handler. Every other by-id GET route in this codebase translates an unknown-id lookup failure to 404; this one didn't. The route now catches LookupError and returns 404. Deployed to the VPS.

Built a disposable e2e-smoketest principal through the real admin-console flow (not a direct DB seed) and called all 86 tools in dependency order (commitments → memory → relationships → drafts/Integrity Gate → calendar → cartographer → correspondent → scribe → identity → audit/compliance), 99 calls total. Result: zero transport failures, zero JSON-RPC dispatch errors, zero unhandled crashes across every tool — the 12 that returned a structured business error were confirmed to be incomplete test arguments, not real gaps, by retesting each with corrected arguments until all 86 succeeded. Critically, "the tool returned success" was not trusted as proof of persistence: cross-checked eva-mcp's own httpx request logs for the actual POST .../rest/v1/<table> calls and their 200/201 status codes underneath every write-shaped tool, the same discipline this session's Integrity Gate work already established for not trusting a green response at face value. This sweep is what surfaced findings #65–67.

MemoryService.retract_fact() (eva_domain/keeper/memory.py:99) calls self.graph_store.retract_fact(...) unconditionally, and correct_fact() calls retract_fact() internally — so both tools shared one missing dependency. InMemoryGraphMemoryStore and DirectNeo4jGraphMemoryStore both implement retract_fact (close the fact's temporal window via valid_to, never delete, per FR-E9-S3), formally required by the GraphMemoryStore Protocol (eva_persistence/stores/graph.py) — but GraphitiGraphMemoryStore, the store actually wired to production, had no such method at all, confirmed by listing every method the class defines. Added it, mirroring the exact same semantics against the store's own fact-id-addressable index (Graphiti's add_episode/search surface exposes no per-episode update, so the index stays the sole source of truth here, the same authority split get_fact/facts_for_subject already rely on). 2 new tests (test_graphiti_store.py), full backend suite 1,408 passed, ruff clean. Live-verified on the VPS against a real principal: both eva_retract_fact and eva_correct_fact now return a clean result instead of an error.

Live-verified during the E2E sweep: ForgetEngine's per-store drop_scope() loop never includes correspondent_classifications, correspondent_decisions, or correspondent_draft_replies at all — confirmed by the actual erasure request log, which shows deletes against 16 other tables but none against these three. Worse, the one adjacent table it does try (deleting correspondent_classifications would have been a no-op fix at best) returned 409 Conflict from a foreign-key constraint (correspondent_decisions_classification_id_fkey) that the untouched correspondent_decisions rows still hold open — and that failure was silently swallowed by the same bare except Exception pattern drop_scope() uses elsewhere. Net effect: a principal's classified email threads, routing decisions, and draft replies survive eva_forget completely untouched. Not fixed this session — found live, not yet scoped.

The erasure request log shows DELETE .../rest/v1/principal_subscriptions?principal_id=eq.e2e-smoketest returning 200 OK, yet the row was still present on the next direct query. Not yet explained — no FK conflict logged the way finding #66's did, so this isn't the same failure shape. Flagged as an open anomaly rather than diagnosed; needs a follow-up pass before trusting eva_forget's coverage of subscription state.

Surfaced while verifying that a live 92-tool-call OpenClaw agent inbox-triage run had actually persisted to the database rather than just being narrated by the LLM: the run's 131 audit rows all showed a blank principal, which first looked like a write-side attribution bug. Traced instead to the reader. SupabaseAuditSink deliberately leaves the top-level principal_id FK column unset (its own docstring: NULL is valid for system events and avoids a principals lookup) and records the real identifier inside the JSONB payload — confirmed by querying payload->>principal_id, which carried ankit-dhir on all 131 rows. But the audit viewer and the health dashboard's "recent activity" (admin_detail_routes.py, this session's console revamp) both filtered and SELECTed the top-level column, so the Principal cell always rendered an em-dash and ?principal_id=… silently returned zero matches — exactly the "read a column that is structurally always NULL" trap the same code already sidestepped for payload->>allowed one field over. Fixed both call sites to payload->>principal_id (returned under the key principal_id by PostgREST's ->> embedding, so the display code is unchanged). Reworked the test fake to model the real shape (principal in the payload, top-level column None) so the test now genuinely guards the fix — reverting to the column makes it fail. Full backend suite 1,443 passed, ruff clean, committed 839ecce. Live-verified on the VPS: /admin/audit?principal_id=ankit-dhir now returns the rows with ankit-dhir populated in the Principal column (was 0 rows / blank before), and the principal + event_type filters compose correctly.