Add end-to-end bridge tests, operational hardening, and release documentation
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Parent: #6
Depends on all implementation issues listed before this issue in #6.
## Purpose
Prove the complete phone-to-Codex supervision flow and establish a release gate for the new bridge mode.
## Scope
- build deterministic integration fixtures for fake Telegram Bot API updates and a controllable PTY child process;
- test command, voice/wizard, worker, streaming output, approval, cancellation, timeout, retry, duplicate update, and restart flows end to end;
- add database migration and backward-compatibility tests;
- add structured local logs/diagnostics with correlation by task/run/request id;
- document service startup, health checks, backup/recovery, troubleshooting, upgrade/rollback, and known limits;
- perform a final senior architecture, security, concurrency, and failure-mode review.
## Acceptance criteria
- [ ] One automated scenario starts a task, observes live output, receives an interaction, approves it, and observes completion.
- [ ] One automated scenario stops a running task and verifies process cleanup and durable state.
- [ ] Duplicate Telegram updates and runner events do not duplicate actions or output.
- [ ] Restart scenarios recover stale runs and pending interactions conservatively.
- [ ] Telegram outage, SQLite busy/error, Codex crash, malformed output, and notification retry paths are covered.
- [ ] All unit/integration tests, docs checks, Sphinx build, compilation, and whitespace checks pass.
- [ ] The first-run guide includes the full live-bridge smoke test.
- [ ] #6 definition of done is verified line by line and the final review records residual risks.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with parent issue #6 and its preceding implementation issues, then review the listed integration scenarios and acceptance criteria. Use the deterministic Telegram Bot API and PTY fixtures, database compatibility tests, documentation checks, Sphinx build, compilation, and whitespace checks as the verification path; done means every acceptance criterion and the #6 definition of done pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, sqlite
- Domain
- backend, databases, devops, documentation, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100