Milestone 3.5.D.4 — Extraction Task Enqueue

Status: Planned
Goal: Track D — Proxy Integration
Phase: 3.5 — Extraction & Context Assembly
Estimated effort: 1 day
Track: Track D — Proxy Integration
Depends on: Milestone 3.5.D.2 (handler wiring)

Why This Milestone Exists

The proxy needs to trigger memory extraction after a completed session. This uses Celery-native Redis list semantics (LPUSH/BRPOP), not Redis Streams — reconciling the ARCHITECTURE.md/milestone doc conflict. The proxy never imports Celery; it speaks the broker's wire protocol directly.

Orientation (indicative)

Named paths, package layouts, libraries, schemas, env vars, and commands anywhere on this page are rough sketches for orientation — inspiration and a baseline, not a required change list.

During implementation, expect to:

open the live tree and follow existing patterns before inventing new ones
research current constraints (latency, tenancy, deploy shape, libraries) more deeply than this page can
advance the design beyond the sketch where measurement or code reality says so
land work in different filenames, merged packages, deferred docs, or new surfaces when the situation calls for it

Prefer outcomes over matching any particular file tree or command sequence.

Areas that may be involved (situational — not a checklist):

Proxy service (HTTP, bootstrap, config)
Context assembly service
Workers / task runtime

Success signals

Outcome-oriented signals that the milestone is in good shape. Exact filenames, package layouts, and commands may differ from any sketches above.

Extraction enqueue fires exactly once per completed session, never on active status
Uses Celery-native Redis list semantics (LPUSH)
Proxy does not import Celery — raw Redis LPUSH with Celery wire format
Repo guards / CI checks still pass

Prerequisites

Milestone 3.5.D.2 (handler wiring)
Phase 3.5 Track A (worker skeleton)