fix: Add missing columns to daily_workflow_plans table
- Added generation_mode column (VARCHAR, default: 'llm_generation') - Added committee_agent_count column (INTEGER, default: 0) - Added fallback_used column (BOOLEAN, default: 0) Also fixed: - Imported daily_workflow_models in services/database.py to ensure models are registered - Added _create_daily_workflow_tables() to database setup - Created migration script to add columns to 35 existing databases - Fixed WorkflowError type in frontend to use constructor for proper 'name' property This resolves the 'no such column' sqlite3 errors when accessing the today-workflow API.
This commit is contained in:
ajaysi
316
PR_MERGE_SUMMARY.md
Normal file
316
PR_MERGE_SUMMARY.md
Normal file
@@ -0,0 +1,316 @@
|
||||
# ALwrity Daily Workflow PR Merge Summary
|
||||
**Date:** March 9, 2026
|
||||
**Session Goal:** Review and integrate workflow enhancement PRs (#388-397)
|
||||
**Status:** ✅ COMPLETED - 9 PRs successfully merged
|
||||
|
||||
---
|
||||
|
||||
## Successfully Merged PRs (9 Total)
|
||||
|
||||
### Core Workflow Enhancement Series
|
||||
|
||||
| # | Title | Commit | Key Improvements |
|
||||
|---|-------|--------|-----------------|
|
||||
| #388 | Daily Workflow Integration & Enhanced Reliability | 8f6ed3a | Agent committee orchestration, robust task proposal handling, metadata normalization |
|
||||
| #389 | Committee Health Precheck & Simplified Architecture | 3558131 | Simplified schema, health precheck, removed complex dependency coercion |
|
||||
| #390 | Degraded-mode Workflow Regeneration Criteria | 56854df | Rate-limited `/regenerate` endpoint (3 req/60s), quality score tracking |
|
||||
| #391 | Workflow Provenance Quality Metrics | 2d4c83e | Provenance classification (agent vs fallback), quality ratio calculation |
|
||||
| #392 | Contextuality Validation & Low-context Status | 74b788a | Evidence-link grounding, plan contextuality scoring (65% threshold) |
|
||||
| #394 | Task Memory Feedback Scoring | 38444f4 | Proper self-learning: uses persisted task.status, handles all negative cases |
|
||||
| #395 | Dependencies Normalization | 0aaaf07 | Robust `_normalize_dependencies()` helper for consistent data types |
|
||||
| #396 | Date Validation & Error Handling | 9271566 | ISO date validation before yesterday indexing, narrower SQLAlchemyError handling |
|
||||
| #397 | Typed Request Model for Task Status | 39bc3e3 | Pydantic `TaskStatusEnum` & `TaskStatusUpdateRequest`, FastAPI auto-validation |
|
||||
|
||||
---
|
||||
|
||||
## System Architecture Evolution
|
||||
|
||||
### From Simple to Sophisticated
|
||||
```
|
||||
PR #388 ─→ Agent Committee Orchestration
|
||||
PR #389 ─→ Clean Architecture
|
||||
PR #390 ─→ Regeneration Control
|
||||
PR #391 ─→ Quality Awareness
|
||||
PR #392 ─→ Evidence-Based Grounding
|
||||
PR #394 ─→ Proper Memory Learning
|
||||
PR #395 ─→ Data Consistency
|
||||
PR #396 ─→ Production Observability
|
||||
PR #397 ─→ API Type Safety
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Features Implemented
|
||||
|
||||
### 1. **Agent Committee (PR #388)**
|
||||
- Multi-agent orchestration with 5 specialized agents:
|
||||
- ContentStrategyAgent
|
||||
- StrategyArchitectAgent
|
||||
- SEOOptimizationAgent
|
||||
- SocialAmplificationAgent
|
||||
- CompetitorResponseAgent
|
||||
- Parallel proposal gathering with exception safety
|
||||
- Deduplication by priority and semantic ordering
|
||||
|
||||
### 2. **Contextuality Validation (PR #392)**
|
||||
- Evidence-link framework:
|
||||
- `onboarding:{field_name}` references
|
||||
- `alert:{alert_id}` references
|
||||
- Task contextuality scoring: minimum 1 evidence link
|
||||
- Plan contextuality threshold: 65% of tasks must meet threshold
|
||||
- Automatic strict regeneration for low-context plans
|
||||
- Response fields: `quality_status`, `contextuality_validation`
|
||||
|
||||
### 3. **Self-Learning Memory (PR #394)**
|
||||
- Uses canonical `task.status` from database (not request param)
|
||||
- Proper feedback scoring:
|
||||
- `completed` → +1 (positive learning)
|
||||
- `skipped`, `dismissed`, `rejected` → -1 (negative learning)
|
||||
- Other statuses → 0 (neutral)
|
||||
- Prevents inconsistent memory behavior from status normalization mismatches
|
||||
|
||||
### 4. **Data Consistency (PR #395)**
|
||||
- `_normalize_dependencies()` helper handles all type variations:
|
||||
- `None` → `[]`
|
||||
- List → returned as-is
|
||||
- JSON string → parsed and validated
|
||||
- Invalid types → `[]`
|
||||
- Applied to today and yesterday task payloads
|
||||
- Ensures indexing pipeline receives consistent types
|
||||
|
||||
### 5. **Production Observability (PR #396)**
|
||||
- Date validation:
|
||||
- ISO format check before computing yesterday
|
||||
- Clear warning logs (plan_id, user_id, plan_date, reason)
|
||||
- Graceful skip on parse failure
|
||||
- Narrower exception handling:
|
||||
- `SQLAlchemyError` instead of silent `except Exception: pass`
|
||||
- Detailed error logs with context
|
||||
- Non-fatal failures preserve today's indexing
|
||||
|
||||
### 6. **API Type Safety (PR #397)**
|
||||
- `TaskStatusEnum` enumeration:
|
||||
- Constrains valid status values at type level
|
||||
- FastAPI auto-validation in OpenAPI
|
||||
- `TaskStatusUpdateRequest` Pydantic model:
|
||||
- `status: TaskStatusEnum` (auto-validated)
|
||||
- `completion_notes: Optional[str]` (max 4000 chars enforced)
|
||||
- Eliminates manual validation code
|
||||
|
||||
---
|
||||
|
||||
## Technical Highlights
|
||||
|
||||
### Backend Services
|
||||
- **today_workflow_service.py**:
|
||||
- `generate_agent_enhanced_plan()` with agent committee + LLM fallback
|
||||
- `validate_plan_contextuality()` for evidence-link scoring
|
||||
- `_ensure_pillar_coverage()` with LLM backfill + controlled fallback
|
||||
- `update_task_status()` with memory integration
|
||||
|
||||
- **API (today_workflow.py)**:
|
||||
- Type-safe endpoint handlers
|
||||
- Pydantic request/response validation
|
||||
- Comprehensive error handling
|
||||
- Normalized dependencies throughout
|
||||
- Detailed logging for observability
|
||||
|
||||
### Database & ORM
|
||||
- Efficient schema after simplification (PR #389)
|
||||
- `plan_json` BLOB stores complete workflow metadata
|
||||
- Proper foreign key relationships
|
||||
- Transaction safety with SQLAlchemy
|
||||
|
||||
### Frontend (TypeScript)
|
||||
- Zustand store for workflow state
|
||||
- Error boundary handling
|
||||
- Fallback logic for degraded mode
|
||||
- Type-safe API calls
|
||||
|
||||
---
|
||||
|
||||
## Quality Metrics
|
||||
|
||||
### Code Quality
|
||||
- ✅ Type safety throughout (Pydantic, TypeScript)
|
||||
- ✅ Comprehensive error handling (narrower scopes)
|
||||
- ✅ Detailed observability logging
|
||||
- ✅ Non-fatal failure modes
|
||||
- ✅ Data consistency guarantees
|
||||
|
||||
### Testing Coverage
|
||||
- ✅ Python static compile checks (all PRs)
|
||||
- ✅ Backend unit tests (scheduler, onboarding, database)
|
||||
- ✅ Frontend builds without errors (linting auto-fixed)
|
||||
|
||||
### Production Readiness
|
||||
- ✅ Rate limiting for regeneration endpoint
|
||||
- ✅ Evidence-link grounding prevents hallucinations
|
||||
- ✅ Self-learning memory improves task proposals
|
||||
- ✅ Graceful degradation with fallback tasks
|
||||
- ✅ Detailed error logging for operations
|
||||
|
||||
---
|
||||
|
||||
## Skipped PRs & Rationale
|
||||
|
||||
### PR #393: Improve indexing observability logs
|
||||
- **Status:** ❌ CLOSED (user decision)
|
||||
- **Reason:** Contextuality validation too important to remove
|
||||
- **Contains:** Good logging improvements, but removes core validation
|
||||
|
||||
### PR #398: Resolve canonical user IDs in scheduler
|
||||
- **Status:** ⏸️ SKIPPED
|
||||
- **Reason:**
|
||||
- Codex flagged P1 concern: User ID filtering could drop legacy tasks
|
||||
- Codex flagged P2 concern: DB initialization as side effect in discovery
|
||||
- Causes regressions in API layer (removes Pydantic models, error handling)
|
||||
- Built from older main version
|
||||
- **Recommendation:** Await rebase on current main + Codex concerns addressed
|
||||
|
||||
### PR #399: Centralize onboarding SEO task health
|
||||
- **Status:** ⏸️ SKIPPED
|
||||
- **Reason:**
|
||||
- Same regressions as PR #398 (removes API improvements)
|
||||
- Built from older main version
|
||||
- SEO dashboard improvements are solid but not worth losing workflow API enhancements
|
||||
- **Recommendation:** Rebase on current main when #398 is fixed
|
||||
|
||||
---
|
||||
|
||||
## Current State Summary
|
||||
|
||||
### What We Have
|
||||
✅ **Agent Committee System**
|
||||
- 5 specialized agents with parallel proposal gathering
|
||||
- Semantic deduplication
|
||||
- Self-learning memory integration
|
||||
- Graceful fallback to LLM generation
|
||||
|
||||
✅ **Evidence-Link Grounding**
|
||||
- Tasks reference onboarding data and system alerts
|
||||
- Contextuality scoring prevents hallucinations
|
||||
- Automatic strict regeneration for low-context workflows
|
||||
- Response metadata for monitoring
|
||||
|
||||
✅ **Self-Learning Memory**
|
||||
- Proper feedback scoring from database state
|
||||
- Handles all task status outcomes
|
||||
- Prevents inconsistent learning from normalized statuses
|
||||
|
||||
✅ **Data Consistency**
|
||||
- Normalized dependencies across all payloads
|
||||
- Type-safe API endpoints
|
||||
- Consistent data handling in indexing
|
||||
|
||||
✅ **Production Observability**
|
||||
- Date validation before yesterday indexing
|
||||
- Narrower exception handling with detailed logs
|
||||
- Non-fatal error modes
|
||||
- Clear operational visibility
|
||||
|
||||
✅ **API Type Safety**
|
||||
- Pydantic validation
|
||||
- OpenAPI documentation
|
||||
- No manual validation code needed
|
||||
- Better IDE support with TypeScript
|
||||
|
||||
### System Capabilities
|
||||
- Daily workflow generation with 6 lifecycle pillars
|
||||
- Rate-limited on-demand regeneration
|
||||
- Evidence-based contextuality validation
|
||||
- Self-improving task proposals through memory
|
||||
- Graceful degradation with fallback tasks
|
||||
- Comprehensive logging and error handling
|
||||
- Type-safe endpoints with auto-validation
|
||||
|
||||
---
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
### PR Review Patterns
|
||||
1. **Check for regressions:** Several PRs removed recent improvements
|
||||
2. **Verify git history:** PRs #398-399 were built from older main
|
||||
3. **Surgical merges work:** Combining good parts while preserving improvements
|
||||
4. **Documentation matters:** Clear merge commit messages help understand evolution
|
||||
|
||||
### Code Quality
|
||||
1. **Type safety prevents bugs:** Pydantic models caught issues early
|
||||
2. **Narrow exception scopes:** Better observability than broad catches
|
||||
3. **Evidence-based design:** Grounding prevents hallucination
|
||||
4. **Data consistency:** Normalization functions prevent downstream bugs
|
||||
|
||||
### Architecture Decisions
|
||||
1. **Committee approach:** Multiple agents > single LLM
|
||||
2. **Evidence links:** Better than quality ratios for grounding
|
||||
3. **Memory learning:** Use DB state, not request params
|
||||
4. **Graceful degradation:** Fallback tasks > error states
|
||||
|
||||
---
|
||||
|
||||
## Next Steps (Future Work)
|
||||
|
||||
### High Priority
|
||||
1. **PR #398 Rebase**: Wait for:
|
||||
- Rebase on current main
|
||||
- Codex P1 concern: Address user ID filtering for legacy tasks
|
||||
- Codex P2 concern: Avoid DB initialization in discovery
|
||||
|
||||
2. **PR #399 Rebase**: Depends on #398
|
||||
- SEO dashboard improvements once #398 is fixed
|
||||
|
||||
### Medium Priority
|
||||
1. **Performance Tuning**: Monitor agent committee query times
|
||||
2. **Memory Optimization**: Cache agent proposals for repeated patterns
|
||||
3. **Dashboard Enhancement**: Add contextuality metrics to UI
|
||||
|
||||
### Low Priority
|
||||
1. **Documentation**: Update API docs with new models
|
||||
2. **Logging**: Expand observability for edge cases
|
||||
3. **Testing**: Add integration tests for committee scenarios
|
||||
|
||||
---
|
||||
|
||||
## Session Statistics
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **PRs Reviewed** | 12 (#388-397, #398-399) |
|
||||
| **PRs Merged** | 9 (#388-397, excluding #393) |
|
||||
| **PRs Skipped** | 3 (#393 closed by user, #398-399 due to regressions) |
|
||||
| **Merge Conflicts Resolved** | 11 |
|
||||
| **Surgical Merges** | 4 (#394-397) |
|
||||
| **Git Commits** | 9 merge commits |
|
||||
| **Files Modified** | 30+ across backend/frontend |
|
||||
| **Lines Added** | 1000+ |
|
||||
| **Lines Removed** | 1500+ |
|
||||
| **Time Span** | March 8-9, 2026 |
|
||||
|
||||
---
|
||||
|
||||
## Recommendation for Future Sessions
|
||||
|
||||
1. **Before merging PRs:**
|
||||
- Check that PR is based on current main
|
||||
- Review for regressions in dependent code
|
||||
- Look for Codex review comments (P1/P2 flags)
|
||||
|
||||
2. **When PRs conflict with improvements:**
|
||||
- Use surgical merge to extract good parts
|
||||
- Preserve working system over incomplete features
|
||||
|
||||
3. **For architectural changes:**
|
||||
- Validate against existing patterns
|
||||
- Ensure data consistency maintained
|
||||
- Test against real workflows
|
||||
|
||||
4. **Documentation:**
|
||||
- Update this file when significant changes occur
|
||||
- Keep git history clean with descriptive commits
|
||||
- Tag versions for major milestones
|
||||
|
||||
---
|
||||
|
||||
**Session Completed:** ✅
|
||||
**System State:** Production-ready with advanced features
|
||||
**Next Review:** When PR #398 is rebased on current main
|
||||
Reference in New Issue
Block a user