# Objective

Implement on the new platform only those forms and public integration scenarios that are required by the new website.

## What to Do

- Based on the inventory results, determine the actually needed forms and user actions.
- Do not migrate legacy form code, Devise/OAuth, or other integrations automatically just because they exist in the old project.
- For each required scenario, design a new implementation using haih-cms and the current stack.
- Set up validation, error messages, and successful submission confirmations.
- Check protection against obvious spam and duplicate submissions.
- Connect external integrations only when there is a confirmed necessity.

## Result

The new website contains an up-to-date set of forms and public integrations without dependency on legacy code.

## Definition of Done

- All necessary user scenarios are implemented.
- Outdated OAuth and other legacy integrations are not migrated automatically.
- Forms operate independently of the Ruby application.
- Sensitive parameters are not recorded in the public task.

Do not migrate legacy form implementations literally; re-implement only the relevant user scenarios on haih-cms.

Re-implement forms and current public integrations from scratch

## Change in Approach to Forms and Integrations

The legacy implementation of forms, OAuth, and external integrations is not being migrated automatically. Only the user scenarios that are actually needed will be re-implemented on the new site.

This makes it possible to eliminate dependence on old Rails gems and outdated providers, and avoids carrying over functionality merely for the sake of compatibility.

Worklog for task "Re-implement forms and current public integrations from scratch"

Change in Approach to Forms and Integrations

Task: Re-implement forms and current public integrations from scratch