v1.2.0: Dex v2 — chat orchestration, proactive priority feed, wired executors & email design system - #3
Conversation
Replace the monkey-patched Discord chat path with a transport-independent, product-grade orchestration foundation, and add the proactive Priority Feed. Channel harness (nexus/communication/channels.py) - ChannelRole: semantic, platform-independent roles (CHAT, NOTIFICATION, PRIORITY_FEED, BRIEFING, APPROVAL, SYSTEM). - ChannelMessage: transport-independent inbound message; every adapter normalizes its native event into this. Orchestration never sees the platform. - ChannelRouter: declarative role <-> channel binding + per-role policy (respond-without-mention, post-only, mention-owner). Chat pipeline (nexus/communication/chat/) - Conversation -> Planner -> ChatAction -> Validator -> Executor. - Typed ChatAction contract; governance flags (requires_owner/requires_approval) are stamped server-side from a trusted table, never inferred from the LLM. - Validator enforces owner/schema/approval gates; Executor performs side effects via injected services and emits a SYSTEM status card. - Per-conversation memory passed to the planner (fixes incoherent follow-ups). Thin Discord adapter (nexus/communication/discord/bot.py) - normalize -> ChatService.handle -> render. No LLM/email/DB logic in the adapter. Proactive Priority Feed (nexus/intelligence/feed.py) - After each research run, high-importance new findings are routed via ChannelRole.PRIORITY_FEED onto the transactional outbox as an owner-tagged, influencer-style digest. Research stays Discord-agnostic. - Outbox discord delivery generalized to honor payload['channel_key'] (defaults to 'summaries' — backward compatible) so one outbox serves every channel role. - Composed into the existing 2-hourly research job; config toggle + threshold. Tests: +17 E2E (channel harness, chat orchestration, priority feed). Gate: 236 passed, ruff clean, mypy clean (69 files).
The remaining chat actions now call real domain services instead of returning 'not wired up yet'. The Executor gains an injected session_factory and event_gateway (provided at startup in api.py) and opens a session per action, mirroring the /task_create slash command path — no duplicated logic. - create_task: TaskService.create_task -> change_status(QUEUED); emits lifecycle events via the gateway. Owner-gated. - run_research: creates and queues a research task routed to the 'nexus' agent runtime (topic preserved as description) — responsive and async. Owner-gated. - show_status: live counts from the DB (health, open tasks, pending approvals, 24h research findings). Open to all. - approval_request: unchanged — short-circuits at the Validator (requires_approval) before reaching the executor. Each side-effecting action emits a SYSTEM status card routed to #console via the channel harness, and every branch is fail-soft (missing config or a service error returns an honest reply + failed card, never crashes). Architecture held: thin adapter, governance stamped server-side in the planner's trusted table, validator schema gates unchanged. Tests: +5 E2E (real DB session factory, scripted LLM, no service mocks): owner create_task persists+queues; non-owner denied persists nothing; missing title schema-fails; run_research queues a nexus-runtime task; show_status reflects seeded counts. Gate: 241 passed, ruff clean, mypy clean (69 files).
Design-first milestone. Establishes the email visual identity of Nexus v2 as a reusable, production-quality, Jinja2 + table-based HTML system. No business logic, no service wiring, no EmailService changes — pure design assets. Foundation - base.html master layout: 600px table shell, mso ghost tables, inline-CSS-first (the <style> block carries only dark-mode + responsive media queries), hidden preheader, accent + content blocks. - 9 component partials as Jinja2 macros: header, footer, section (+panel, code_block), metric_card (+metric_row), badge, status_chip, divider (+spacer), button (+VML button_row), timeline, table (data_table, kv_grid, progress). Email types (extend base.html, one accent each) - 12 operational: morning_digest, operational_intelligence, research_report, todo_digest, reminder, approval_required, execution_completed, execution_failed, security_alert, scheduler_report, weekly_review, monthly_executive. - 4 conversational (Q&A family): qa_transcript, conversation_summary, action_items, decision_summary (remaining formats documented as presets). Documentation - EMAIL_DESIGN_SYSTEM.md — philosophy, architecture, semantic + subsystem colour system, type scale, spacing/radius/elevation, icon strategy, placeholder schema, future-extension strategy (Discord/Slack/Teams/web/PDF). - EMAIL_STYLE_GUIDE.md — voice & tone, colour/writing rules, accent-per-type, 55 subject-line patterns, accessibility checklist. - EMAIL_COMPONENT_LIBRARY.md — per-component signatures, params, examples, variants, higher-order patterns, Q&A family mapping. - EMAIL_TEMPLATE_GUIDELINES.md — authoring model, client-compatibility matrix, responsive + dark-mode rules, charts approach, per-type specifications, rendering instructions, design-only integration seam, QA checklist. Verification & extras - sample_context.json: concrete placeholder payloads (the data schema). - previews/: 3 rendered HTML examples. - All 16 templates verified to render via Jinja2 with realistic data, light/dark and desktop/mobile, with zero unresolved tags. Compatibility: Gmail, Outlook (Word/VML), Apple Mail; dark mode; mobile-first responsive; no external images, web fonts, or JS.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6369129e3e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| async with get_session(self.session_factory) as session: | ||
| memory_service = MemoryService(session) | ||
| task_service = TaskService(session, memory_service, self.event_gateway) |
There was a problem hiding this comment.
When ChatService is built in api.py, self.event_gateway is the live gateway with WorkflowOrchestrator subscribers. Passing it into TaskService here makes change_status(...QUEUED) synchronously publish TASK_UPDATED before this get_session block commits the newly created task; the orchestrator opens its own DB session for the approval request and cannot see the uncommitted task, so chat-created tasks can be reported as queued while no approval/execution is created. Defer publishing until after the transaction commits or route this through the DB outbox.
Useful? React with 👍 / 👎.
| channel_name = getattr(message.channel, "name", None) | ||
| in_chat_channel = self.router.respond_without_mention(channel_name) |
There was a problem hiding this comment.
When Discord channels are configured by ID (which get_channel_by_config supports), this reverse lookup uses the channel name while ChannelRouter stored the configured ID string, so in_chat_channel is false. In that deployment, messages in the configured CHAT channel without an @ mention never reach ChatService, and the no-mention chat channel only works for name-based configs. Use message.channel.id as well or map both IDs and names.
Useful? React with 👍 / 👎.
| if _to and not yaml_data["email"].get("to_address"): | ||
| yaml_data["email"]["to_address"] = _to |
There was a problem hiding this comment.
If config/settings.yaml already defines email.to_address, NOTIFY_EMAIL_TO is ignored because this guard only assigns when the YAML value is empty, even though the surrounding env mapping treats deployment env as overriding YAML and the comment says an explicit recipient wins. In deployments changing the recipient via env, operational/chat emails continue going to the stale YAML address.
Useful? React with 👍 / 👎.
1 participant
Summary
Promotes the
v1.2.0-planningline intomaster. Becausemastercurrently sits behind the v1.1.0 release, this PR bundles both the v1.1.0 stabilization work and the v1.2.0 Dex-v2 increments. Net: 246 files, ~16.2k insertions / ~1.1k deletions across 9 commits.What's included
v1.2.0 — Dex v2 (product-grade chat, proactive feed, email design system)
14d04d1): transport-independentChannelMessage+ semanticChannelRole, declarativeChannelRouter, and theConversation → Planner → Validator → Executorpipeline. Governance (requires_owner/requires_approval) is stamped server-side from a trusted table, never inferred from the LLM. Thin Discord adapter (normalize → handle → render). Replaces the prior monkey-patched chat path.ChannelRole.PRIORITY_FEEDonto the existing transactional outbox as an owner-tagged digest. Research stays Discord-agnostic; outbox discord delivery generalized to honorpayload["channel_key"](defaults tosummaries— backward compatible).b88b3c8):create_task,run_research(routed to thenexusagent runtime), andshow_statusnow call real domain services via an injectedsession_factory/event_gateway;approval_requestshort-circuits at the Validator. Each side-effecting action emits a SYSTEM status card; every branch is fail-soft.6369129): design-first, Jinja2 + table-based HTML.base.htmlmaster layout + 9 component partials, 12 operational + 4 conversational templates, 4 design docs,sample_context.json, and rendered previews. Gmail/Outlook(VML)/Apple Mail compatible, dark-mode, mobile-first. NoEmailServicechanges, no service wiring — pure assets.988b793): v1.2 charter, roadmap, evidence-backed tech-debt backlog.v1.1.0 — Pilot operational validation & Nexus branding
26fc0fdrelease commit;c4c4f3cHermes H-4 pilot lifecycle (fail-fast init, configurable budgets, terminate/cancel, TIMED_OUT, resume);d6bd75dHermes H-2 honesty fixes;b734c13Track S default-secure sandbox;2fd3ffcv1.1.0 planning charter.Quality gates
Notes / non-goals
🤖 Generated with Claude Code