alexei.dolgolyov
1d445f3980
Rework entity schema: rename Tracker→NotificationTracker, add CommandConfig/ CommandTracker/CommandTrackerListener entities for decoupled command handling. Commands now resolve through CommandTracker→CommandConfig instead of TelegramBot.commands_config. Smart ref-counted bot polling based on active listeners. Add chat_action to telegram targets. Full frontend CRUD pages for command configs and command trackers. Idempotent SQLite migrations. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
74 lines
3.0 KiB
Markdown
74 lines
3.0 KiB
Markdown
# Phase 7: Integration & Cleanup
|
|
|
|
**Status:** ⬜ Not Started
|
|
**Parent plan:** [PLAN.md](./PLAN.md)
|
|
**Domain:** fullstack
|
|
|
|
## Objective
|
|
Final integration pass: verify end-to-end flows, clean up deprecated code paths,
|
|
update CLAUDE.md entity relationship documentation, and ensure everything works
|
|
together.
|
|
|
|
## Tasks
|
|
|
|
- [ ] Task 1: Verify notification flow end-to-end:
|
|
- ServiceProvider → NotificationTracker → NotificationTrackerTarget → NotificationTarget
|
|
- Watcher detects changes → dispatches through renamed entities
|
|
- Scheduled/periodic/memory notifications still work
|
|
|
|
- [ ] Task 2: Verify command flow end-to-end:
|
|
- CommandTracker → CommandConfig + CommandTrackerListener (TelegramBot)
|
|
- Incoming command via webhook/polling → resolved through command tracker
|
|
- Bot ref-counting: start/stop polling based on listener count
|
|
|
|
- [ ] Task 3: Clean up deprecated code:
|
|
- Remove any remaining backward-compatibility aliases in models.py
|
|
- Remove any old route files that were renamed (trackers.py, tracker_targets.py)
|
|
- Remove any unused imports
|
|
- Ensure no references to old model names remain anywhere
|
|
|
|
- [ ] Task 4: Update CLAUDE.md "Entity Relationships" section:
|
|
- Document new schema: ServiceProvider capabilities, NotificationTracker, CommandTracker, CommandConfig, CommandTrackerListener
|
|
- Update the entity relationship diagram
|
|
- Update Template System Sync Rules if affected
|
|
|
|
- [ ] Task 5: Verify migration idempotency:
|
|
- Fresh database: all tables created correctly
|
|
- Existing database with old schema: migration runs without errors, data preserved
|
|
- Running migration twice: no errors
|
|
|
|
- [ ] Task 6: Clean up any TODO markers left by previous phases
|
|
|
|
- [ ] Task 7: Verify frontend-backend integration:
|
|
- All frontend pages load and display data correctly
|
|
- CRUD operations work for all entities
|
|
- Command tracker listener add/remove triggers bot polling start/stop
|
|
|
|
## Files to Modify/Create
|
|
- `packages/server/src/notify_bridge_server/database/models.py` — cleanup aliases
|
|
- `CLAUDE.md` — update entity relationships documentation
|
|
- Various files — cleanup TODOs and unused code
|
|
|
|
## Acceptance Criteria
|
|
- Full notification flow works: provider → notification tracker → target
|
|
- Full command flow works: command tracker → command config → listener → bot
|
|
- No references to old model/route names remain
|
|
- CLAUDE.md accurately documents new entity schema
|
|
- Server starts cleanly with both fresh and migrated databases
|
|
- Frontend builds and all pages functional
|
|
|
|
## Notes
|
|
- This phase is primarily verification and cleanup — no major new features.
|
|
- If integration issues are found, fix them in this phase rather than going back.
|
|
- The old plans/entity-relationship-refactor/ files from previous attempts can be kept as historical record.
|
|
|
|
## Review Checklist
|
|
- [ ] All tasks completed
|
|
- [ ] Code follows project conventions
|
|
- [ ] No unintended side effects
|
|
- [ ] Build passes
|
|
- [ ] Tests pass (new + existing)
|
|
|
|
## Handoff to Next Phase
|
|
<!-- This is the final phase — no handoff needed. -->
|