Nexus: End-of-Sprint Human Notification with LORE RAG Summary

[Christiantyemele]

Overview

At the end of every sprint, Nexus should notify humans via its gateway and connected channels, providing a comprehensive sprint summary generated from the RAG knowledge accumulated by LORE (the documentation and institutional memory agent).

Current State

• LORE generates sprint retrospectives (retrospective.rs) with basic metrics: tickets completed, carried over, blockers, highlights, and lessons learned
• LORE maintains Architecture Decision Records (ADRs), changelogs, and documentation
• Nexus orchestrates the pipeline but has no end-of-sprint notification capability
• Nexus Gateway exists (crates/nexus-gateway/) but no sprint notification logic
• No mechanism exists to summarize LORE's RAG knowledge for human stakeholders

Requirements

1. Sprint End Detection

• Nexus should detect when a sprint has ended (configurable sprint duration)
• Trigger notification workflow automatically at sprint boundary
• Sprint boundaries could be time-based or milestone-based

2. LORE RAG Knowledge Integration

• Query LORE's accumulated knowledge for the sprint period:
  • Sprint retrospectives (docs/retrospectives/*.md)
  • Architecture Decision Records (docs/adr/*.md)
  • Changelog entries (CHANGELOG.md)
  • Documentation updates
• Use RAG to synthesize a coherent sprint summary from these sources
• Include key decisions made, architectural changes, and lessons learned

3. Human Notification via Gateway

• Use Nexus Gateway to send notifications to connected channels:
  • Slack (already referenced in persona)
  • Email
  • GitHub issue/comment
  • Webhook
• Notification should include:
  • Sprint summary (generated from LORE RAG)
  • Tickets completed vs planned
  • Key architectural decisions made
  • Blockers encountered and resolved
  • Lessons learned
  • Upcoming sprint priorities (based on milestones)

4. Sprint Summary Format

The generated summary should include:

• Sprint Overview: Dates, tickets completed, velocity
• Key Deliverables: What was shipped/merged
• Architectural Decisions: ADRs created during sprint
• Challenges & Resolutions: Blockers and how they were overcome
• Lessons Learned: From retrospectives and team feedback
• Next Sprint Outlook: Based on milestone due dates and remaining backlog

Implementation Approach

Files to Create/Modify

• crates/nexus-gateway/src/sprint_notification.rs — New notification module
• crates/agent-lore/src/rag_summary.rs — RAG-based sprint summary generation
• crates/agent-nexus/src/lib.rs — Sprint end detection and notification trigger
• orchestration/agent/agents/nexus.agent.md — Update persona with sprint notification responsibilities
• crates/config/src/state.rs — Add sprint configuration and notification settings

Integration Points

• LORE: Query existing retrospectives, ADRs, changelogs
• Nexus Gateway: Send notifications via configured channels
• SharedStore: Track sprint boundaries and notification state
• GitHub API: Post sprint summary as issue/comment if configured

Acceptance Criteria

• Sprint end is detected automatically (time-based or milestone-based)
• LORE's RAG knowledge is queried and synthesized into a summary
• Human notification is sent via configured channels (Slack, email, GitHub)
• Sprint summary includes: deliverables, ADRs, blockers, lessons learned
• Notification is formatted and readable for human stakeholders
• Sprint notification state is tracked to prevent duplicate notifications
• Existing LORE retrospective generation is enhanced, not replaced
• All existing tests pass
• New tests for sprint notification and RAG summary generation

Dependencies

• Requires LORE's existing retrospective and documentation infrastructure
• Requires Nexus Gateway to be configured with notification channels
• May require RAG/vector store integration for knowledge retrieval

Notes

This feature closes the loop on autonomous development by ensuring humans are kept informed at sprint boundaries without manual intervention. The RAG-based approach means the summary is grounded in actual project knowledge (ADRs, retrospectives, changelogs) rather than generic metrics.