Skip to content

ADR-0019: Remove Legacy Application Generation

Status

ACCEPTED

Date: 2026-07-27

Changelog

Date Revision Description Author
2026-07-27 1.0 Initial version Loryth maintainers

Context

The repository contains two architectural generations. The maintained generation uses FastAPI services and shared libraries under server/, the pnpm frontend workspace under ui/, and the services, database bootstrap, migration runner, and gateways defined by the current Docker Compose topology.

An older generation remains at the top level as a Flask application, a separate React application, and a monolithic database initialization tree. That generation does not participate in the canonical Compose topology. Keeping both generations makes product maturity and ownership ambiguous, increases maintenance burden, and creates a material risk that agents and developers modify the wrong implementation.

Decision

The maintained server/ and ui/ generation and the current Docker Compose topology are canonical. Remove the obsolete top-level application generation, including its Flask API, separate React application, monolithic database initialization and migration tooling, and legacy-only editor and operational configuration.

Database creation remains owned by docker/postgres/. Schema migration discovery remains owned by docker/migrations/ and the SQL migrations within maintained services. Historical source remains retrievable through Git history; no archived source copy or compatibility layer will be kept in the working tree.

Legacy-only behavior is not considered migrated merely because a maintained bounded context has a related name. Capabilities such as discourse discussions, standalone time tracking and reports, habit tracking, the old filesystem and notebook experience, the settings registry, and older project, task, group-administration, and journal interfaces are removed. They may return only after intentional product design and implementation in maintained bounded contexts.

Consequences

Positive

  • Contributors have one canonical backend, frontend, and local deployment topology.
  • Product ownership and implementation maturity are less ambiguous.
  • Obsolete dependencies and configuration no longer consume maintenance attention.
  • Agents and developers are less likely to change an unsupported implementation.

Negative

  • Legacy-only capabilities are no longer present in the working tree or runnable from the repository.
  • Recovering historical behavior requires consulting Git history.

Neutral

  • Related maintained services do not imply feature or data-model parity with the removed generation.
  • Reintroducing a removed capability requires fresh product and architecture decisions.

Alternatives Considered

  1. Keep the legacy generation during a transition period
    • Rejected because the legacy generation is no longer supported or transitional and does not participate in the canonical runtime.
  2. Archive the legacy source within the repository
    • Rejected because an archive would preserve ambiguity and duplicate Git's historical record.
  3. Rebuild legacy-only capabilities as part of this cleanup
    • Rejected because replacement product development is explicitly outside this decision.

References