Servify Implementation Backlogs
This directory splits architecture implementation tasks by topic.
Purpose:
- Keep each backlog readable
- Let server, AI, SDK, and protocol integration each advance independently
- Support interrupt and resume
File descriptions:
Overall Architecture Design
- Macro boundaries, runtime layering, and future extension directions
Current Architecture Analysis
- Current real architecture snapshot, module migration status, and transition risks
Architecture Redesign Plan
- Architecture redesign plan (a services→modules migration-era artifact, archived only)
- Platform tasks such as entry, bootstrap, router, auth, event bus, and realtime
- provider, AI orchestration, tooling, knowledge indexing, and related tasks
- conversation, routing, agent, ticket, customer, automation, analytics, voice
04-sdk-and-channel-adapters.md
- sdk core, web sdk, future api/app sdk reservations, channel adapters, SIP adapter
- CI, testing pyramid, release versioning, documentation site
06-voice-and-protocol-expansion.md
- deeper voice protocol entries, provider landing, and more common voice protocol reservations
- web sdk wrap-up, deeper future api/app sdk contracts, transport evolution
- LLM/knowledge provider expansion, orchestration layer stability, AI observability
09-runtime-and-repo-hygiene.md
- runtime artifact cleanup, repository hygiene, ignore policy, cross-platform dev environment convergence
10-service-to-module-migration.md
- migrating legacy services/handlers to the modules architecture, adapter layers, and boundary convergence
- current handlers/services/modules migration inventory and priority suggestions
- current migration completeness table and module status tracking
- handlers/services/modules migration-era boundary rules and freeze policy
- multi-tenancy, permission model, audit logging, configuration boundaries
- tracing, metrics, logging, alerting, replay, and operational diagnostics
- P0: wire up the AI agent loop (tool-calling loop + streaming), so the intelligent customer service can act in multiple steps
Status conventions:
[ ]not started[-]in progress[x]done
Execution suggestions:
- Do
01-platform-and-runtimefirst - Then do
02-ai-and-knowledge - Then split
03-business-modules - Plan
04-sdk-and-channel-adaptersin parallel (web sdk is implemented; Android/iOS native SDKs landed with M1–M3; api/app sdk remain reservations) - After the first phase is cleared, enter the
05to08engineering and expansion phase
Current progress (updated 2026-10-04, v1.0.0 released):
01through08are all cleared09completed repository hygiene and runtime artifact governance10services→modules migration is complete (internal/servicesfully removed, capped at 27 first-level modules); the accompanying inventory / scorecard / boundaries docs are migration-era archives11and12have mostly landed (tenant/audit/security baseline wired into the management surface; tracing/metrics/ alerting pass the observability baseline gate)13the AI agent loop main loop is wired (tool-calling loop + streaming + three-tool registration; wiring the tool Port data sources and permission checks is left over; see the verification note at the top of 13-ai-agent-loop.md)- The V1.0 convergence batches (B0–B4) have all passed the gate; the only active status sources are todo.md and the acceptance matrix; for future evolution see "Evolution Directions"
Current reading order:
- Read Current Architecture Analysis first to confirm the repository's real state.
- Then read the V1.0 Convergence Plan to confirm the current product/architecture baseline.
- The historical implementation mainline (architecture redesign plan, 10-series migration archives) serves only as migration history reference.
Companion topics:
- Release Versioning Strategy
- Testing Pyramid
- Mermaid Compatibility
- Repository Hygiene and Generated Asset Boundaries