Web App dependency: classroom persistence and safe Social access

Tracking issue: #221.

Owner: Prompthon Web App / Social Media Manager stream. Status: requires implementation and production verification. Handbook integration is intentionally independent of production deployment.

Evidence reviewed on 2026-08-30

The current local Web App checkout has organization-scoped Social canonical entities and migrations in apps/social-media-manager-agent/src/server/. It does not expose a confirmed course workspace/persistence API. apps/web/src/services/agent/localBridgeRequestAuth.ts is explicitly deprecated and states that active product routes use normal request-user authentication; the legacy verifier is retained only for historical tests. The existing Handbook Social Skill's bridge-token examples therefore cannot be assumed to authenticate the current deployment.

This was a source inspection, not a probe of an authenticated production tenant. Exact public API behavior and DB/schema placement still require the owner to confirm them. No local database credential was read or copied for this work.

Required implementation

1. Provision instructor-approved demo/course workspaces using existing Prompthon users and organization membership. Issue short-lived, revocable course capabilities through the current signed-in app; never distribute Neon credentials or reinstate retired bridge authentication.
2. Implement contract v1 with server-side validation, tenant membership enforcement on every row, optimistic revisions, idempotency, rate limits and mandatory canonical readback.
3. Decide whether the course domain uses tables/schema in the existing application Neon database or an isolated course database. Put migrations, RLS/application enforcement and connection configuration in the backend repo. Record this decision; the Handbook cannot infer it from local SQLite.
4. Reuse existing Social campaign/post/variant/schedule/channel models and active auth. Provide a server-attested demo organization/channel view for the course wrapper; reject production channels even if a student edits a plan. No social_campaigns_v2 or client database access.
5. Provide instructor setup/cleanup, a UI or authenticated API inspection view for run/artifact/domain readback, request ids and operational telemetry. Demo reset must not touch active runs or real business/Social data.
6. Supply the real course origin, scope onboarding and disposable staging credentials to instructors through approved secret channels. Test cross-student isolation and persistence across restart on Neon before enabling remote exercises.

Release gate

Record the owning backend issue/PR, migration decision, deployment id, environment, sanitized scope/readback evidence and remaining limitations. Until those are verified, Handbook local exercises and contract tests are available, while production course persistence and server-backed social scheduling remain blocked dependencies. A placeholder URL, CLI success, mocked response or static SQL proposal is not release evidence.

First-party platform references

The intended hosting split is documented by Vercel Postgres integration guidance and Neon's Vercel connection guide. They describe hosting/connection mechanisms, not the existence of Prompthon's course API.