[dshakes]

Part 3 of 11 of the GA next-gen stack. Replaces #264/#255–#263: same changes, history rewritten to drop a 43 MB build binary committed by mistake, plus part 11 fixing every confirmed Codex cross-audit finding. Base: ga2/02-cp-security-cost. Merge in order with a merge commit (not squash).

Context, verification and needs-human list: #254 and docs/roadmap/2026-10-nextgen-sandbox-and-harness.md.

Commits in this part:

• merge: bridge commitment ledger, parity gate, sent-log, typecheck in CI

[github-actions]

🔎 Codex cross-audit (agent:audit)

Blocking
No blocking issue found.

High

• services/imessage-bridge/src/session.ts:8750 and services/whatsapp-bridge/src/session.ts:9878: noteDraftMeta() is called after the contact reply has already been sent. The send boundary calls appendSentLog() during send() / sendMessage() (iMessage line 6071, WhatsApp line 3619), so the current reply logs without tier/delta. Worse, the metadata remains in the map and can be consumed by the next send to that handle within 10 minutes, misattributing the previous reply’s tier/delta to a later message. Move noteDraftMeta() before the burst send loop, or pass the metadata directly into the send/log call.

Medium

• packages/bridge-core/src/commitments-edge.ts:606: the commitment ledger says done evidence must be a verbatim evidence line, but the guard accepts any normalized substring of the whole evidence blob. The new test even closes on "just sent Raju the deck" when the actual line is "me: just sent Raju the deck, check your inbox". Since this path calls client.done() and mutates real commitments, a model can close a task with a partial phrase instead of the exact evidence line the prompt requires. Build a normalized set of full evidence lines and require equality against one of those lines.

I tried npm test in packages/bridge-core, but this checkout has no installed tsx, so the suite failed at loader startup rather than exercising the PR. CI’s new npm ci step should avoid that in Actions.

[compass-sdlc-bot]

🔒 Reviewer verdict: BLOCKING — Found one blocking correctness bug: sent-log tier/voiceDelta metadata is recorded after the message is already sent, so it never attaches to the right entry.

[github-actions]

🛡️ Vuln scan — ❌ vulnerable dependency found

      #41: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls trace.Shutdown
      #42: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls trace.Shutdown
      #43: internal/telemetry/tracer.go:92:21: telemetry.InitTracer calls trace.TracerProvider.Shutdown
      #44: internal/handlers/runtime.go:186:50: handlers.NewGRPCSchedulerClient calls otelgrpc.NewClientHandler, which calls trace.TracerProvider.Tracer
      #45: internal/telemetry/tracer.go:79:23: telemetry.InitTracer calls trace.WithBatcher
      #46: internal/telemetry/tracer.go:80:24: telemetry.InitTracer calls trace.WithResource
      #47: internal/telemetry/tracer.go:81:23: telemetry.InitTracer calls trace.WithSampler
      #48: internal/handlers/llm_proxy.go:3935:104: handlers.LlmProxyHandler.Transcribe calls trace.errUnsupportedSampler.Error
      #49: internal/telemetry/tracer.go:17:2: telemetry.init calls trace.init
      #50: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls trace.init
      #51: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls trace.logDropped
      #52: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls trace.logDropped
      #53: internal/handlers/llm_proxy.go:3810:27: handlers.LlmProxyHandler.OCR calls io.ReadAll, which eventually calls trace.nonRecordingSpan.AddEvent
      #54: internal/handlers/runtime.go:1556:2: handlers.RuntimeHandler.Schedule calls trace.nonRecordingSpan.End
      #55: internal/middleware/span.go:34:22: middleware.EnrichSpan calls trace.nonRecordingSpan.IsRecording
      #56: internal/handlers/runtime.go:1564:19: handlers.RuntimeHandler.Schedule calls trace.nonRecordingSpan.RecordError
      #57: internal/handlers/runtime.go:1555:20: handlers.RuntimeHandler.Schedule calls trace.nonRecordingSpan.SetAttributes
      #58: cmd/server/main.go:841:38: server.main calls http.Server.ListenAndServe, which eventually calls trace.nonRecordingSpan.SetName
      #59: internal/handlers/runtime.go:1565:17: handlers.RuntimeHandler.Schedule calls trace.nonRecordingSpan.SetStatus
      #60: internal/handlers/runtime.go:1554:27: handlers.RuntimeHandler.Schedule calls noop.Tracer.Start, which calls trace.nonRecordingSpan.SpanContext
      #61: internal/handlers/llm_proxy.go:3801:24: handlers.LlmProxyHandler.OCR calls http.Client.Do, which eventually calls trace.nonRecordingSpan.TracerProvider
      #62: internal/handlers/llm_proxy.go:3810:27: handlers.LlmProxyHandler.OCR calls io.ReadAll, which eventually calls trace.recordingSpan.AddEvent
      #63: internal/handlers/runtime.go:1556:2: handlers.RuntimeHandler.Schedule calls trace.recordingSpan.End
      #64: internal/middleware/span.go:34:22: middleware.EnrichSpan calls trace.recordingSpan.IsRecording
      #65: internal/handlers/runtime.go:1564:19: handlers.RuntimeHandler.Schedule calls trace.recordingSpan.RecordError
      #66: internal/handlers/runtime.go:1555:20: handlers.RuntimeHandler.Schedule calls trace.recordingSpan.SetAttributes
      #67: cmd/server/main.go:841:38: server.main calls http.Server.ListenAndServe, which eventually calls trace.recordingSpan.SetName
      #68: internal/handlers/runtime.go:1565:17: handlers.RuntimeHandler.Schedule calls trace.recordingSpan.SetStatus
      #69: internal/handlers/runtime.go:1554:27: handlers.RuntimeHandler.Schedule calls noop.Tracer.Start, which calls trace.recordingSpan.SpanContext
      #70: internal/handlers/llm_proxy.go:3801:24: handlers.LlmProxyHandler.OCR calls http.Client.Do, which eventually calls trace.recordingSpan.TracerProvider
      #71: internal/handlers/llm_proxy.go:3935:104: handlers.LlmProxyHandler.Transcribe calls trace.samplerArgParseError.Error
      #72: internal/handlers/connector_health.go:177:15: handlers.PersistConnectorQuarantine calls errors.As, which eventually calls trace.samplerArgParseError.Unwrap
      #73: internal/handlers/runtime.go:1554:27: handlers.RuntimeHandler.Schedule calls trace.tracer.Start
      #74: internal/telemetry/tracer.go:86:27: telemetry.InitTracer calls otel.SetTextMapPropagator, which eventually calls trace.tracerProviderConfig.MarshalLog
      #75: internal/telemetry/tracer.go:79:23: telemetry.InitTracer calls trace.WithBatcher, which eventually calls x.Feature[string].Enabled
      #76: internal/telemetry/tracer.go:16:2: telemetry.init calls resource.init, which calls x.init

Vulnerability #15: GO-2026-6443
    Server panic via missing authority or Host headers in google.golang.org/grpc
  More info: https://pkg.go.dev/vuln/GO-2026-6443
  Module: google.golang.org/grpc
    Found in: google.golang.org/grpc@v1.82.1
    Fixed in: google.golang.org/grpc@v1.82.2
    Example traces found:
      #1: cmd/server/main.go:263:32: server.main calls grpc.Server.Serve, which eventually calls transport.http2Server.HandleStreams

Vulnerability #16: GO-2026-6348
    Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation in
    google.golang.org/grpc
  More info: https://pkg.go.dev/vuln/GO-2026-6348
  Module: google.golang.org/grpc
    Found in: google.golang.org/grpc@v1.82.1
    Fixed in: google.golang.org/grpc@v1.83.1
    Example traces found:
      #1: internal/handlers/runs.go:447:25: handlers.RunService.StreamRunEvents calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.StreamRunEventsRequest, github.com/dshakes/lantern/gen/go/lantern/v1.StreamEvent].Send, which eventually calls mem.BufferSlice.MaterializeToBuffer
      #2: internal/handlers/runs.go:447:25: handlers.RunService.StreamRunEvents calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.StreamRunEventsRequest, github.com/dshakes/lantern/gen/go/lantern/v1.StreamEvent].Send, which eventually calls mem.IsBelowBufferPoolingThreshold
      #3: internal/handlers/runs.go:447:25: handlers.RunService.StreamRunEvents calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.StreamRunEventsRequest, github.com/dshakes/lantern/gen/go/lantern/v1.StreamEvent].Send, which eventually calls mem.NewBuffer
      #4: internal/handlers/dataplane.go:519:30: handlers.DataPlaneService.RunStream calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamClientMsg, github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamServerMsg].Recv, which eventually calls mem.ReadAll
      #5: internal/handlers/llm_proxy.go:3935:104: handlers.LlmProxyHandler.Transcribe calls multierr.multiError.Error, which eventually calls mem.writer.Write
      #6: internal/handlers/runtime.go:1984:27: handlers.RuntimeHandler.StreamLogs calls grpc.GenericClientStream[github.com/dshakes/lantern/gen/go/lantern/v1.LogsRequest, github.com/dshakes/lantern/gen/go/lantern/v1.RuntimeLogLine].Recv, which eventually calls transport.ClientStream.Close
      #7: internal/handlers/runtime.go:354:28: handlers.pumpExec calls grpc.clientStream.CloseSend, which eventually calls transport.ClientStream.Header
      #8: internal/handlers/dataplane.go:519:30: handlers.DataPlaneService.RunStream calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamClientMsg, github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamServerMsg].Recv, which eventually calls transport.ClientStream.Read
      #9: internal/handlers/dataplane.go:519:30: handlers.DataPlaneService.RunStream calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamClientMsg, github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamServerMsg].Recv, which eventually calls transport.ClientStream.RecvCompress
      #10: internal/handlers/runtime.go:354:28: handlers.pumpExec calls grpc.clientStream.CloseSend, which eventually calls transport.ClientStream.TrailersOnly
      #11: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls transport.NewHTTP2Client
      #12: cmd/server/main.go:263:32: server.main calls grpc.Server.Serve, which eventually calls transport.NewServerTransport
      #13: internal/handlers/dataplane.go:519:30: handlers.DataPlaneService.RunStream calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamClientMsg, github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamServerMsg].Recv, which eventually calls transport.ServerStream.Read
      #14: internal/handlers/dataplane.go:519:30: handlers.DataPlaneService.RunStream calls grpc.GenericServerStream[github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamClientMsg, github.com/dshakes/lantern/gen/go/lantern/v1.DpRunStreamServerMsg].Recv, which eventually calls transport.Stream.ReadMessageHeader
      #15: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls transport.http2Client.Close
      #16: internal/handlers/schedules.go:237:33: handlers.RESTHandler.UpdateSchedule calls time.LoadLocation, which eventually calls transport.http2Client.GracefulClose
      #17: internal/handlers/runtime.go:354:28: handlers.pumpExec calls grpc.clientStream.CloseSend, which eventually calls transport.http2Client.NewStream
      #18: cmd/server/main.go:906:25: server.main calls grpc.Server.GracefulStop, which eventually calls transport.http2Server.Close
      #19: cmd/server/main.go:263:32: server.main calls grpc.Server.Serve, which eventually calls transport.http2Server.HandleStreams

Your code is affected by 16 vulnerabilities from 3 modules and the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 19
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.
make: *** [Makefile:270: audit] Error 3

[github-actions]

🔷 Gemini cross-audit (agent:audit-gemini)

Blocking

1. Out-of-Order Execution Breaks Sent-Log Metadata (noteDraftMeta called after send loop)

• Files: services/imessage-bridge/src/session.ts (lines 8685 vs 8749), services/whatsapp-bridge/src/session.ts (lines 9820 vs 9874)
• Issue: In both bridges, this.send(...) / this.sendMessage(...) is called inside the burst loop. Each send call synchronously invokes logSentReply() / appendSentLog(), which calls takeDraftMeta(handle, now). However, noteDraftMeta(handle, { tier, voiceDelta }) is positioned after the burst send loop finishes.
• Impact:
  1. Every outbound contact reply is logged to sent-log.jsonl with tier: undefined and voiceDelta: undefined.
  2. noteDraftMeta populates draftMeta after the message has already left. That metadata sits in memory until the next message to that handle (even hours or days later), where takeDraftMeta pops the stale metadata from the prior conversation turn.
  3. takeDraftMeta calls draftMeta.delete(k). Even if noteDraftMeta were moved before the loop, any multi-message burst (burst.length > 1) would delete the metadata on message 0, causing messages 1..n to log tier: undefined.
• Fix: Call noteDraftMeta before the burst send loop. In takeDraftMeta, do not delete the metadata immediately upon reading if multiple burst messages are in flight, or peek by handle during the burst window.

---

Non-Blocking & Edge Cases

2. Dual-Bridge Commitment Judgment Causes Duplicate Closes and Self-Chat FYIs

• Files: services/imessage-bridge/src/session.ts, services/whatsapp-bridge/src/session.ts, packages/bridge-core/src/commitments-edge.ts
• Issue: Both bridges schedule runCommitmentJudgment() on their proactive ticks (~6h) and read from their own independent stateDir/commitment-ledger.json. Both query the shared control-plane /v1/commitments?status=open.
• Impact: When a commitment is fulfilled, both bridges can independently evaluate it, call client.done(e.id), and emit ✅ closed: <title> notifications to owner self-chat on both iMessage and WhatsApp.
• Fix: Coordinate ledger state or qualify commitment closing by channel attribution/source to prevent duplicate FYIs across bridges.

3. judgeCommitments Substring Boundary & Unhandled stale State

• File: packages/bridge-core/src/commitments-edge.ts (judgeCommitments, runCommitmentJudgment)
• Issue:
  • hay collapses all evidence into a single space-separated string (normWs(evidence.join("\n"))). hay.includes(normWs(ev)) can match a phrase spanning the end of one evidence line and the start of the next.
  • The model is instructed to return state: "stale" for irrelevant commitments, but runCommitmentJudgment only handles e.state === "done". Stale commitments are never dismissed on the server via client.dismiss(e.id); they remain open in the backend database indefinitely.

4. Non-Deterministic npm install in CI Lint Workflow

• File: .github/workflows/sdlc-lint.yml (line 134)
• Issue: The workflow uses npm ci for bridge-core and imessage-bridge, but uses npm install --no-audit --no-fund for whatsapp-bridge. npm install can resolve unpinned transitive updates and bypass strict lockfile validation in CI.
• Fix: Update services/whatsapp-bridge/package-lock.json if needed and use npm ci.

5. False Alarm on First Introspect Run

• File: scripts/introspect/run.sh (lines 58–69)
• Issue: On a fresh deploy before any introspect run has completed ($STATE_DIR/last-success absent and no REPORT-*.md), SUCCESS_MARK is empty and immediately fires ALARM: no successful introspect run has ever been recorded before the script even executes Claude.
• Fix: Suppress the alarm when running the initial bootstrap/first run or check whether $STATE_DIR was newly initialized.

[dshakes]

Superseded: the history rewrite on this stack accidentally re-signed master's commits (base diverged). Replaced by a range-limited rewrite on ga3/* — see the new GA 1/11 PR.