Rectify EmailBrain around the intended Swift/Rust adapter-capable product path#6
Open
Rectify EmailBrain around the intended Swift/Rust adapter-capable product path#6
Conversation
…duct path This replaces the incomplete Python backend with the Rust Axum service, restores the frontend API layer, moves the app onto the 3900/3901 ports, and realigns the runtime so adapter-backed chat follows the LM Studio path by default while JKCA remains an explicit base-chat fallback. The reasoning is that the product idea and the live runtime had drifted apart: the UI advertised adapters, the docs contradicted the implementation, and the old default provider could not satisfy the adapter contract. The commit also fixes the broken Swift ingestion surface by removing the duplicate LoRA extraction path, tying success UI to the actual backend response, and making extraction operate on the selected email. The remaining Python tooling is kept only where it still adds value for training/testing adapters, with the trainer and test harness updated to consume the extracted schema and target the local EmailBrain API rather than LM Studio directly. Risk areas are the LM Studio dependency for adapter-backed chat, the seeded adapter path still requiring a real adapter artifact, and the optional JKCA fallback remaining dependent on that runtime being available when selected. These changes were taken because the previous state could compile in pieces but did not reliably express the authoritative product intent end-to-end.
Owner
Author
|
@codex review |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
…emediation This release packages the backend, frontend, Swift, and adapter-tooling changes that were driven by the 50-edge-case investigation and then validated with targeted checks and live HTTP probes. Behavior: - hardens the Rust API around input validation, pagination, deduplication, safer CORS aliases, bounded logging, safer adapter-path handling, and clearer provider failures - upgrades the Next.js client with abortable data fetching, safer date formatting, semantic selection controls, adapter recovery, dynamic endpoint labels, and local chat transcript continuity - fixes the Swift Mail bridge to prefer the selected message, stop fabricating empty-mail placeholders, preserve recipients and thread metadata when available, honor configurable backend URLs, and avoid leaking message content to stdout - makes the LoRA scripts resolve paths from the repo instead of caller cwd and tolerate missing optional Python backend config imports Reasoning: - the prior product path relied on optimistic local assumptions, which caused ambiguous failures, stale UI state, filesystem drift, and poor operator feedback once the local runtimes were missing or misconfigured - the chosen path keeps diffs reviewable and reversible while moving failures to the boundary where they can be reported deterministically Evidence: - cargo test passed in backend (11 tests) - npm run type-check passed in frontend - python3 -m py_compile passed for adapters/test_lora.py and adapters/train_lora.py - xcrun swiftc -typecheck passed for swiftmail/mailbrain/mailbrain/*.swift - live probes confirmed backend health, frontend reachability, email ingest/list/detail, duplicate-ingest handling, bad-date rejection, invalid-id rejection, empty-prompt rejection, and localhost/127.0.0.1 CORS aliasing; remaining chat failures were traced to missing LM Studio and missing adapter artifacts rather than code regressions Risk: - base chat still depends on LM Studio running at the configured endpoint - adapter chat still depends on a real adapter existing on disk for the seeded registry path
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR rectifies EmailBrain back toward its intended product shape: a local-first email assistant centered on Swift ingestion, a Rust backend, a working web UI, and an adapter-capable chat path.
Behavioral Changes
:3901.:3900.Implications
Risk Areas
Confidence By Area
Verification
swiftc -typecheckon the Swift app sourcesxcodebuild -project swiftmail/mailbrain/mailbrain.xcodeproj -scheme mailbrain -sdk macosx CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO buildpython3 -m py_compile adapters/train_lora.py adapters/test_lora.py backend/config.pycargo test --manifest-path backend/Cargo.tomlnpm run buildinfrontendnpm run lintinfrontend:3901for/healthEMAILBRAIN_INFERENCE_PROVIDER=jkca, confirming adapter traffic no longer fails with the old provider-contract400What To Look At
backend/src/main.rsswiftmail/mailbrain/mailbrain/ContentView.swiftandswiftmail/mailbrain/mailbrain/MailService.swiftswiftmail/mailbrain/mailbrain/EmailExtractor.swiftandadapters/train_lora.pyREADME.md,architecture_analysis.md, anddocs/sequence-diagram.mdNext Steps