8.3 KiB
EMI local translation production readiness — 2026-08-18
Goal
Read-only production-readiness discovery for EMI’s local MarianMT translation service and deployed backend integration.
Scope and boundaries
- Project / hosts: EMI; Mac mini
.102as Factory/Paseo control host and EMI production server.119as the intended runtime host. - Repository / runtime: Mac-mini backend workspace
/Users/adolforeyna/Projects/EMI/EMI-Backend; intended production checkout/home/aeroreyna/EMI-Backendand its Docker Compose backend/translation containers. - Allowed: explicit
auto-reviewPaseo verifier; non-mutating source/runtime inspection and bounded non-persistent HTTP only where runtime access is available. - Forbidden: edits, commits, pushes, pulls, stashes/resets/cleans, image build/pull/rebuild, service/container restart/recreate/deploy, migrations, credential or configuration changes, and proxy/firewall changes.
- Approval gate: human approval before any isolated worktree, source/configuration change, merge, deployment, restart, or container lifecycle action.
Coordinator continuity
- Feature session:
emi: local-translation-production-readiness(Factory profile). - Existing production Paseo workspace recorded by project definition:
wks_fc39b6c9d2ebc9e0on.119; it was not reachable from this Factory control session because the production daemon is loopback-only and direct SSH asaeroreyna@emi-serverwas denied.
Paseo evidence
| Role | Agent ID | Workspace ID | Provider / mode | Terminal state |
|---|---|---|---|---|
| Read-only runtime verifier | 9b8ca9a7-193f-4162-bd3d-d9f861a518d9 |
wks_740a1fe0494b5cc9 (EMI · Backend — Mac mini Checkout) |
codex/gpt-5.6-terra, explicitly auto-review |
idle / completed |
The agent located/read the applicable parent workspace guidance before source inspection. Paseo inspection confirmed its available mode included auto-review, no pending permissions, and no worktree was created. No source or runtime mutation was requested or reported.
Observed contract (static only — not production runtime verification)
The verifier’s read-only source inspection found:
- Compose intends an internal
app↔translationconnection onemi-network; app upstream ishttp://translation:8000. Translation has no published host port. - The app defaults to
TRANSLATION_PROVIDER=openai; local MarianMT is used only when the runtime provider is explicitlymarian. GET /healthis implemented as200 application/jsonwith{"status":"ok","provider":"marianmt","loadedModels":[...]}. This is a liveness/in-memory model-name signal only; it does not prove required-model cache availability, successful inference, or readiness.POST /translateacceptstext,sourceLang, andtargetLang. Missing/invalid text or target and unsupported languages are intended to return400; unhandled translation failures are intended to return502 {"status":"Translation failed"}.- Models load lazily on first translation into
/models; the app’s upstream timeout is 30 seconds. - Compose declares neither a container healthcheck nor CPU/memory limits.
Runtime-verification result and blocker
The verifier attempted only read-only runtime-discovery commands (docker compose ps --all, filtered docker ps, and filtered docker volume ls) and found docker: command not found; docker-compose, podman, and nerdctl were also unavailable. Process inspection was restricted (ps: operation not permitted), and no listener on local ports 8000 or 3001 was observable.
Accordingly, it did not install tools, alter permissions, authenticate, enter containers, inspect caches, invoke a translation request, or induce a model download. The only completed evidence is the static contract above. The following production facts remain unverified: running container identity/network/upstream; actual provider value; app-to-translation DNS/TCP/HTTP; /health response from the deployed service; functional translation; first-download/cache behavior; live invalid/upstream-timeout behavior; current resource use; and deployed resource limits.
Exact production-readiness acceptance criteria
Production readiness is not met until a read-only verifier with access to the actual .119 Compose runtime records all of the following:
- Runtime identity and isolation: exact app and translation container IDs/images, Compose project, Docker network membership, and non-secret app upstream mapping; translation is reachable only through the intended internal path unless explicitly approved otherwise.
- Provider correctness: runtime evidence that the app is configured to use
marian, not the static defaultopenai, and that its upstream resolves to the intended translation service. - Connectivity: a non-mutating request from the running app container resolves
translation, completes TCP/HTTP to port 8000, and receives the expected response within the configured bound. - Health/readiness semantics: exact deployed
/healthstatus, headers, and body are captured; a readiness criterion explicitly proves every required model is locally available for inference without triggering a download. A liveness-only200is insufficient. - Functional translation: one bounded, innocuous translation for each approved language direction succeeds through the app’s real translation path; response schema/text and elapsed time are recorded, with no user data persisted.
- First-model/cache behavior: cache volume/path, ownership, persistence across planned container recreation, and required model artifacts are evidenced. First-download latency, network dependency, disk impact, and failure behavior are measured in a controlled approved environment—not by deleting a production cache.
- Errors and timeouts: invalid request returns a documented non-5xx client error; upstream unavailable/timeout behavior is tested without stopping production (or in an approved equivalent environment) and returns the documented bounded error without crashing/retrying indefinitely; the app’s 30-second upstream bound is verified.
- Resources: deployed CPU/memory reservation/limit and current idle/translation peak CPU, RSS, disk/cache consumption are recorded; observed peaks stay below an owner-approved host budget with headroom. No configured resource limits is a blocker.
- Operational controls: Compose/service healthchecks, logs/metrics sufficient to distinguish model download, model load, inference failure, timeout, and resource exhaustion, plus an approved rollback procedure, are documented and independently checked.
- Release integrity: all implementation changes exist in one isolated worktree, pass declared checks, receive independent review, and obtain explicit human approval before merge/build/recreate/deploy.
Proposed isolated-worktree implementation plan (not authorized or started)
- Obtain a read-only production-runtime observability path (Paseo agent on
.119or authorized Docker metadata/log/exec access) and complete acceptance items 1–8 without lifecycle changes. - After human approval and protection/review of the dirty production Compose state, create one isolated backend worktree from the approved committed base, e.g. branch
factory/emi-local-translation-readiness; do not use either dirty main checkout. - Implement a non-downloading readiness endpoint/check that verifies configured required models are present and loadable; keep existing liveness semantics separate and document status/error contracts.
- Add Compose healthchecks and explicit, owner-approved CPU/memory constraints; make model-cache volume persistence, permissions, and prewarming strategy explicit.
- Add deterministic tests for provider selection, health/readiness distinction, validation errors, upstream timeout/error mapping, and cache-present/cache-absent behavior without external model downloads in ordinary CI.
- In an approved non-production environment, measure cold first-download, warm-cache translation, resource peaks, timeout behavior, and recovery; document production rollout and rollback steps.
- Dispatch an independent reviewer and verifier against that isolated worktree. Present exact diff, checks, measured evidence, deployment/recreate impact, and rollback plan for explicit human approval; only then may a named deployment executor act.