P10-S5: ship beta hardening and launch readiness

.ai/active/SPRINT_PACKET.md

@@ -2,7 +2,7 @@
 
 ## Sprint Title
 
-Phase 10 Sprint 4 (P10-S4): Daily Brief + Notifications + Scheduled Open-Loop Review
+Phase 10 Sprint 5 (P10-S5): Beta Hardening + Launch Readiness
 
 Historical baseline marker: Phase 10 Sprint 1 (P10-S1): Identity + Workspace Bootstrap.
 
@@ -12,21 +12,21 @@ feature
 
 ## Sprint Reason
 
-`P10-S1` shipped hosted identity, workspace bootstrap, device management, and preferences. `P10-S2` shipped Telegram transport, channel linking, normalized inbound messages, routing, and delivery receipts. `P10-S3` shipped chat-native continuity and approval handling. `P10-S4` now adds the scheduled habit loop: daily brief generation, notification policy enforcement, quiet-hours-respecting delivery, and scheduled prompts for waiting-for and stale open-loop review.
+`P10-S1` shipped hosted identity, workspace bootstrap, device management, and preferences. `P10-S2` shipped Telegram transport, channel linking, normalized inbound messages, routing, and delivery receipts. `P10-S3` shipped chat-native continuity and approval handling. `P10-S4` shipped daily brief delivery, notification policy, quiet hours, and scheduled prompts. `P10-S5` is the launch gate sprint: beta onboarding hardening, support/admin visibility, analytics and observability for hosted chat flows, rate limiting and abuse controls, rollout flags, and launch-facing product clarity.
 
-Reference baseline markers: `P10-S1` Identity + Workspace Bootstrap, `P10-S2` Telegram Transport + Message Normalization, and `P10-S3` Chat-Native Continuity + Approvals.
+Reference baseline markers: `P10-S1` Identity + Workspace Bootstrap, `P10-S2` Telegram Transport + Message Normalization, `P10-S3` Chat-Native Continuity + Approvals, and `P10-S4` Daily Brief + Notifications + Scheduled Open-Loop Review.
 
 ## Sprint Intent
 
-- daily brief generation and Telegram delivery
-- notification policy enforcement including quiet hours and user preferences
-- scheduled waiting-for and stale-item prompts
-- scheduled open-loop review nudges that reuse shipped `P10-S3` review actions
-- deterministic job and delivery evidence without widening into launch tooling
+- beta onboarding funnel hardening
+- support and admin visibility for hosted Telegram operations
+- analytics and observability for hosted chat and scheduled delivery flows
+- rate limiting, abuse controls, and rollout-flag enforcement
+- launch assets and hosted-vs-OSS product clarity without widening feature scope
 
 ## Git Instructions
 
-- Branch Name: `codex/phase10-sprint-4-daily-brief-notifications`
+- Branch Name: `codex/phase10-sprint-5-beta-hardening-launch`
 - Base Branch: `main`
 - PR Strategy: one sprint branch, one PR
 - Merge Policy: squash merge only after review `PASS` and explicit approval
@@ -42,89 +42,87 @@ Reference baseline markers: `P10-S1` Identity + Workspace Bootstrap, `P10-S2` Te
   - `P10-S1` hosted auth, workspace bootstrap, device management, preferences, beta cohorts, and feature flags
   - `P10-S2` Telegram transport, link/unlink, normalization, routing, and delivery receipts
   - `P10-S3` Telegram chat-native continuity, open-loop review, and approval handling
+  - `P10-S4` Telegram daily briefs, notification policy, quiet hours, and scheduled prompts
   - Phase 9 shipped scope is baseline truth, not sprint work
 - Required now:
-  - daily brief compilation from durable continuity state
-  - scheduler execution and due-job selection
-  - notification policy enforcement using timezone, quiet hours, and brief preferences
-  - scheduled waiting-for and stale open-loop prompts delivered through shipped Telegram transport
-- Explicitly out of `P10-S4`:
+  - beta onboarding readiness and failure-state hardening
+  - support/admin surfaces for hosted operational inspection
+  - analytics, observability, rate limiting, and abuse controls
+  - rollout-flag enforcement and launch-facing documentation clarity
+- Explicitly out of `P10-S5`:
   - new hosted auth, session, or workspace bootstrap flows
   - Telegram transport or link/unlink contract redesign
   - generic chat-native capture/recall/resume/correction behavior already shipped in `P10-S3`
-  - support/admin dashboards
+  - daily brief and notification feature redesign already shipped in `P10-S4`
   - broad channel expansion beyond Telegram
-  - launch hardening
+  - new product-surface scope beyond the Phase 10 plan
 
 ## Exact APIs In Scope
 
-- `GET /v1/channels/telegram/daily-brief`
-- `POST /v1/channels/telegram/daily-brief/deliver`
-- `GET /v1/channels/telegram/notification-preferences`
-- `PATCH /v1/channels/telegram/notification-preferences`
-- `GET /v1/channels/telegram/open-loop-prompts`
-- `POST /v1/channels/telegram/open-loop-prompts/{prompt_id}/deliver`
-- `GET /v1/channels/telegram/delivery-receipts`
-- `GET /v1/channels/telegram/scheduler/jobs`
+- `GET /v1/admin/hosted/overview`
+- `GET /v1/admin/hosted/workspaces`
+- `GET /v1/admin/hosted/delivery-receipts`
+- `GET /v1/admin/hosted/incidents`
+- `GET /v1/admin/hosted/rollout-flags`
+- `PATCH /v1/admin/hosted/rollout-flags`
+- `GET /v1/admin/hosted/analytics`
+- `GET /v1/admin/hosted/rate-limits`
 
 ## Exact Data Additions In Scope
 
-- `continuity_briefs`
-- `daily_brief_jobs`
-- `notification_subscriptions`
-- additive scheduled-delivery fields required on `channel_delivery_receipts` and related scheduler/job records
+- `chat_telemetry`
+- additive rollout, support, incident, and rate-limit evidence fields required on hosted delivery / job / workspace records
 
 ## Exact Files And Modules In Scope
 
 - `apps/api/src/alicebot_api/main.py`
 - `apps/api/src/alicebot_api/contracts.py`
 - `apps/api/src/alicebot_api/store.py`
 - `apps/api/src/alicebot_api/telegram_channels.py`
-- `apps/api/src/alicebot_api/chief_of_staff.py`
-- `apps/api/src/alicebot_api/continuity_open_loops.py`
-- new daily-brief / notification scheduling helpers under `apps/api/src/alicebot_api/`
+- `apps/api/src/alicebot_api/telegram_notifications.py`
+- new hosted admin / telemetry / rollout helpers under `apps/api/src/alicebot_api/`
 - API migrations under `apps/api/alembic/versions/`
-- hosted brief-preference / notification-status pages or components under `apps/web/app/` and `apps/web/components/`
+- hosted admin / support / onboarding-status pages or components under `apps/web/app/` and `apps/web/components/`
 - sprint-owned unit, integration, and web tests under `tests/` and `apps/web/app/**/*.test.tsx`
-- sprint-owned documentation updates required to keep active control truth aligned
+- sprint-owned launch-facing docs and product-clarity updates required to keep control truth aligned
 
 ## Implementation Workstreams
 
 ### API And Persistence
 
-- add brief/job/subscription contracts and persistence for scheduled delivery
-- add due-job selection and delivery bookkeeping that reuses shipped Telegram delivery seams
-- persist scheduled prompt and brief outcomes without creating a parallel chat history model
+- add telemetry, rollout, incident, and rate-limit contracts needed for hosted beta operations
+- add support/admin query surfaces that summarize hosted workspace, delivery, and failure posture without mutating shipped product behavior
+- persist launch-gate evidence without creating a second truth source for the underlying continuity flows
 
-### Delivery Behavior
+### Hardening And Launch
 
-- compile useful daily brief payloads from durable continuity and chief-of-staff state
-- enforce timezone, quiet hours, and notification preferences before delivery
-- deliver scheduled waiting-for and stale-item prompts that point back into shipped `P10-S3` open-loop review handling
+- harden onboarding and hosted flow failure handling around the already shipped Phase 10 surfaces
+- enforce rollout flags and abuse/rate-limit protections on hosted chat and scheduled delivery paths
+- make hosted-vs-OSS product boundaries explicit in launch-facing docs and surfaces
 
 ### Verification
 
-- add unit coverage for brief compilation, quiet-hours gating, and due-job selection
-- add integration coverage for all `P10-S4` endpoints, including quiet-hours suppression, disabled notifications, repeated-job idempotency, and stale-item prompt delivery
-- add web tests for brief-preference / notification-status UX if sprint-owned UI changes are introduced
+- add unit coverage for rollout gating, rate limiting, and telemetry aggregation helpers
+- add integration coverage for admin/support endpoints, rollout-flag enforcement, abuse/rate-limit behavior, and hosted failure-state visibility
+- add web tests for sprint-owned admin/support or onboarding-status UX
 - keep control-doc truth checks passing after packet and current-state updates
 
 ## Required Deliverables
 
-- daily brief compiler and Telegram delivery path
-- notification preference and quiet-hours enforcement
-- scheduled waiting-for and stale-item prompts
-- persisted brief/job/subscription evidence
-- status surface for brief and notification posture
+- beta onboarding hardening
+- hosted admin/support visibility
+- analytics and observability for hosted chat and scheduled delivery flows
+- rate limiting, abuse controls, and rollout flags
+- launch-facing docs and OSS-versus-hosted product clarity
 
 ## Acceptance Criteria
 
-- a linked Telegram user with notifications enabled can receive a useful daily brief generated from durable stored state
-- quiet hours and notification preference settings suppress or defer delivery deterministically
-- waiting-for and stale open-loop prompts are generated and delivered without reopening generic open-loop review semantics already shipped in `P10-S3`
-- delivery jobs and receipts are persisted with deterministic status evidence
-- `P10-S1`, `P10-S2`, and `P10-S3` semantics remain baseline truth and are not reopened as sprint work
-- no `P10-S4` endpoint or screen claims that beta admin/support tooling or launch hardening is already active
+- hosted beta operators can inspect workspace, delivery, incident, and rollout posture without touching the database directly
+- hosted chat and scheduled-delivery paths enforce rollout and abuse/rate-limit controls deterministically
+- onboarding and hosted failure states are visible enough to support a beta user without reopening shipped feature seams
+- launch-facing docs and surfaces clearly distinguish OSS Alice Core from hosted Alice Connect beta scope
+- `P10-S1` through `P10-S4` semantics remain baseline truth and are not reopened as sprint work
+- no `P10-S5` work widens scope beyond beta hardening and launch readiness
 
 ## Required Verification Commands
 
@@ -135,19 +133,19 @@ Reference baseline markers: `P10-S1` Identity + Workspace Bootstrap, `P10-S2` Te
 ## Review Evidence Requirements
 
 - `BUILD_REPORT.md` must list the exact sprint-owned files changed and the exact command results above
-- `REVIEW_REPORT.md` must grade against `P10-S4` specifically, not generic Phase 10 planning
+- `REVIEW_REPORT.md` must grade against `P10-S5` specifically, not generic Phase 10 planning
 - if local archive paths remain dirty, they must be called out explicitly as excluded from sprint merge scope
 
 ## Implementation Constraints
 
 - do not fork continuity semantics between hosted surfaces and Alice Core
 - keep OSS versus product boundaries explicit in docs and API naming
 - preserve existing approval, provenance, and correction discipline
-- do not widen `P10-S4` into beta admin tooling or launch work
-- reuse the shipped `P10-S1`, `P10-S2`, and `P10-S3` identity/workspace/channel/chat foundations instead of duplicating control-plane state
-- do not re-implement generic open-loop review actions that already shipped in `P10-S3`; this sprint only adds scheduled prompting and brief delivery
+- do not widen `P10-S5` into new feature-surface scope beyond hardening and launch readiness
+- reuse the shipped `P10-S1` through `P10-S4` identity/workspace/channel/chat/scheduling foundations instead of duplicating control-plane state
+- do not re-implement generic continuity, approval, or notification behavior that already shipped in earlier sprints
 - prefer additive hosted-control-plane seams over invasive rewrites of shipped Phase 9 paths
 
 ## Exit Condition
 
-`P10-S4` is complete when a linked Telegram user can receive a daily brief and scheduled waiting-for/stale prompts under deterministic quiet-hours and notification-policy enforcement, with persisted job and delivery evidence and no reopening of hosted identity, transport, or generic chat-continuity scope.
+`P10-S5` is complete when hosted beta operations have enough onboarding hardening, support/admin visibility, telemetry, rollout control, abuse protection, and launch-facing documentation clarity to treat Phase 10 as a launch-ready beta without reopening shipped identity, transport, chat-continuity, or notification scope.

.ai/handoff/CURRENT_STATE.md

@@ -8,8 +8,9 @@
 - `P10-S1` (Identity + Workspace Bootstrap) is shipped.
 - `P10-S2` (Telegram Transport + Message Normalization) is shipped.
 - `P10-S3` (Chat-Native Continuity + Approvals) is shipped.
-- `P10-S4` (Daily Brief + Notifications + Scheduled Open-Loop Review) is the active execution sprint packet.
-- No scheduled daily-brief and notification loop is shipped yet.
+- `P10-S4` (Daily Brief + Notifications + Scheduled Open-Loop Review) is shipped.
+- `P10-S5` (Beta Hardening + Launch Readiness) is the active execution sprint packet.
+- No launch-ready beta hardening surface is shipped yet.
 
 ## Canonical Baseline
 
@@ -31,8 +32,8 @@
 - `P10-S1` shipped the hosted account/session foundations, workspace bootstrap, device management, preferences, and beta controls.
 - `P10-S2` shipped Telegram transport, link/unlink flow, message normalization, routing, and delivery receipts.
 - `P10-S3` shipped chat-native continuity behavior and approval handling on top of the shipped Telegram transport.
-- `P10-S4` covers daily brief delivery, notification policy, quiet hours, and scheduled waiting-for / stale-item prompts.
-- Launch hardening is the later Phase 10 milestone.
+- `P10-S4` shipped daily brief delivery, notification policy, quiet hours, and scheduled waiting-for / stale-item prompts.
+- `P10-S5` covers beta onboarding hardening, support/admin visibility, analytics/observability, rollout/rate-limit controls, and launch-facing product clarity.
 - Phase 9 shipped scope is baseline truth and must not be reopened as sprint work.
 
 ## Active Constraints