Required demo backend capability — not yet provisioned

Tracked by issue #221. The browser adapter is executable client code tested against a synthetic Host, but these course-specific endpoints and simulation policy are an explicit dependency. The existing canonical Social service does not become classroom-safe merely because a client sets a demo flag.

Server contract

Under the common scoped course prefix, implement authenticated GET /social-context?preparedRunId=...&planSha256=.... Resolve the real actor and verify course membership, organization, workspace, prepared skill run and plan. Return organization_id, workspace_id, application_id: prompthon.social-media-manager, host_workspace_id, environment: demo, isolated_demo: true, delivery_mode: simulation, short-lived expires_at, permitted social:draft|schedule|publish capabilities and channels[\{id,provider,delivery_mode\}].

These fields must derive from server-owned workspace/provider bindings, not caller JSON or a channel name. Bind the course workspace to its actual Host workspace and canonical Social organization. Require UUID organization ids where the Host contract does. Reject missing/stale capability, cross-tenant references and production channels before a write. The normal signed-in browser session must be supported; never export cookies or grant students Host signing/database secrets.

The common GET /records/content_strategies/:id must work for that authorized browser context so the adapter can verify current strategy revision. Student input must not bypass the server policy by calling the Host operation route directly: enforce course roles, allowed providers, operation scope and simulation delivery in the Host/app dispatch and background workers as well.

Reuse canonical campaigns/posts/variants/schedules/publish-targets/deliveries/audit. Add course strategy linkage to their existing metadata; do not create parallel social tables. Draft remains draft. Demo scheduling creates visible canonical schedule records but cannot reach external provider execution. Demo publish creates canonical per-provider delivery evidence with status simulated and no external post URL. Client-side checks or disabled UI buttons alone do not satisfy this requirement.

Implement authenticated POST /social/record-receipts with prepared_run_id, plan_sha256, action, receipt_ids. Look up actual Host receipts server-side, check actor/workspace/action/resource ownership, inspect canonical readbacks and append common skill_runs evidence. Do not trust arbitrary caller-supplied success snapshots. Return a run_id that the browser can GET and verify with matching scope, succeeded status and metadata.plan_sha256. Use idempotency and reconcile partial operations; do not blindly replay an uncertain external request.

Browser use after deployment verification

Keep the real signed-in Host page open in the in-app browser. Confirm origin, organization and course workspace from live context. Load the reviewed scripts/course_browser.js without auto-running it, then call PrompthonCourseSocial.execute(plan, \{action: 'draft', planSha256: plan.plan_sha256, confirm: 'DRAFT'\}) only after explicit draft authorization. Schedule/publish simulation needs separate SCHEDULE/PUBLISH authorization; the helper never infers it from a content plan.

The adapter refuses redirects, missing capabilities, stale strategies, wrong targets and mismatched readbacks. A partial result includes known ids/receipt ids and requires recovery before retry. Never use local-auth bypass, the historical bridge helper, real provider channels or a direct database connection to get around this dependency.

Acceptance evidence

Use an isolated demo org with two synthetic providers, a course actor and a second forbidden org. Show successful canonical draft/readback, explicit scheduling approval, simulated worker output, blocked production/cross-org operations, unknown-provider refusal, expired capability, stale strategy, idempotent recovery and durable course run readback. Verify no external provider requests. Local Node tests exercise the client protocol only; they do not prove backend provisioning or a real schedule.