Registration confirmation screen should prompt sign-up actions (Slack, Telegram, tweet, YouTube), like the old after-sign-up page did

content_sync/course_repository.py::_parse_course、courses/models/cohort.py、既存の migration/admin パターン、courses/templates/courses/_registration_done.html から着手し、何かを変更する前に対象を絞った登録テストを確認してください。オプションの HTTPS リンクがフィールドあり・なしの両方で取り込まれ、Slack と Telegram の行が明記されたルールに従い、検証とマイグレーションのチェックに合格し、対象を絞った検証とレンダリング検証で受け入れ基準をカバーできれば完了です。

Summary

Complete the post-registration "what to do next" prompts with the per-course community links the old per-course after-sign-up.md files carried: the course Slack channel and the Telegram announcements channel. The sitewide slice already landed on main; what remains is the course.yaml/Course schema addition this issue flagged for grooming, plus the screen rows it feeds.

Grooming decisions

• Per-course links: build the schema. There is no verified sitewide Telegram URL anywhere in the repository, and the historical Telegram channels were strictly per-course (t.me/<course-channel>), so optional per-course fields are the only faithful path.
• Confirmation email: no community prompts. The screen is the moment; the email keeps its verify-email focus. This closes the "page, email, or both" question as page-only.
• Display rules: when the course defines a Telegram link, the screen gains a Telegram row; when it defines a Slack link, the Slack row points at the course link instead of the sitewide one; tweet and YouTube rows stay sitewide. Absent links render no row and no empty state.
• FAQ: stays out of scope. It is not one of the four prompts in the idea, and faq_url keeps its existing uses.

Already delivered on main (context; do not redo)

Commits 79999b43, 406442fd, ba34634c, beb950da landed the email-verification gate, the conditional verify-email row, and the sitewide Slack, tweet, and YouTube rows in courses/templates/courses/_registration_done.html, with coverage in courses/tests/test_registration_email_verification.py.

Normative references

• Registration flow: _docs/specs/04-courses-and-cohorts.md (Registration section).
• course.yaml schema and authoring: _docs/content-authoring.md; parser in content_sync/course_repository.py::_parse_course (strict allowed-field mapping, _https_url validation with JSON pointers).
• Database-only public content: _docs/architecture/database-only-content.md. Per-course links are ingested course data rendered from model/context, not template constants; the sitewide rows already on main are site chrome.
• Design system: _docs/design/design-system.md (the existing row-list pattern on the registration panel).
• Process and verification: _docs/PROCESS.md, _docs/specs/10-verification-strategy.md, _docs/ci/change-selective-ci.md.

Scope and behavior

1. Schema: course.yaml gains two optional course-level fields, slack_url and telegram_url, siblings of faq_url; both validate as HTTPS URLs through the existing _https_url parser idiom (/slack_url, /telegram_url pointers). Existing files without them parse exactly as today.
2. Model: Course in courses/models/cohort.py gains the matching optional URL fields, one migration, and admin exposure following the existing course-field pattern.
3. Ingest: content_sync maps the new CourseSource fields to the model and includes them in validation and replay identity exactly like existing course fields.
4. Display: the registration confirmation screen's next-steps list adds a Telegram row when the course has telegram_url, and swaps the Slack row's target to the course link when it has slack_url (sitewide fallback otherwise). Row copy follows the existing title/description/CTA shape; the view passes the course links in context.
5. No redirect, modal, or tracking behavior; the rows are plain links with the existing external-link conventions (target="_blank", rel="noopener noreferrer").

Non-goals

• No community prompts in the confirmation email; the email changes nothing.
• No per-course variants of the tweet, YouTube, or FAQ prompts.
• No per-course tweet text; the existing share text stays.
• No click analytics, join-state tracking, modals, or one-time dismissal.
• No revival of after-sign-up.md files in course repositories.

Dependencies

None external. The change touches content_sync, courses (model, migration, admin, view, template), and focused tests.

Acceptance criteria

• A course with slack_url/telegram_url in course.yaml ingests cleanly; the confirmation screen shows the Telegram row and the Slack row pointing at the course link, per the display rules.
• A course without the fields ingests exactly as today, and its confirmation screen renders unchanged (sitewide Slack row, no Telegram row).
• Non-HTTPS or malformed values fail ingest validation with the existing pointer-style messages.
• Migration-drift check passes; admin lists and edits the new fields per the existing pattern.
• Focused Django coverage covers ingest with and without the fields, the display rules, and the absence behavior; existing registration tests stay green.
• Desktop and mobile rendering in light and dark keeps the next-steps list intact: rows wrap naturally, no overflow or overlap, new rows match the existing row pattern.
• Engineer handoff and independent tester-final report bind the frozen base/head, verification-plan digests, and screenshot evidence per _docs/ci/change-selective-ci.md.

Meaningful verification scenarios

• Django/integration: ingest a course fixture with and without the new fields; render the registration confirmation for both; assert the row replace/add/absent rules and ingest validation failures.
• Browser (tester): a registrant's confirmation screen for a course with links and a course without, desktop 1440×900 and mobile 390×844, light and dark; external links carry the correct targets; screenshots under .tmp/screenshots/.
• Repository/operations: the diff stays confined to the schema/parser, model/migration, admin, view, template, and their tests; no email template changes.