Skip to content

Tenir compte de « Accessible à toute heure » dans la timeline d'une sortie programmée #539

Closed

Description

@PaulThiberville

Contexte

Epic : #14
Orchestration › Timeline · Modele-de-Donnees (places.always_open) · D-049

Découverte de CODE pendant #36 (PR #536, Inbox du 19/10) : timelineOf (apps/api/src/planned/snapshot.ts) passe à computeTimeline des étapes sans alwaysOpen, et PlannedRouteSnapshot ne garde pas ce champ. Un lieu « Accessible à toute heure » sans horaires reçoit donc hours_unknown dans GET /me/planned, alors que GET /routes/:id/timeline (routeTimelineOf) ne lui en met aucun, comme le veut D-049. Les heures des deux timelines sont identiques (testé), seuls les conflits diffèrent.

Comportement attendu

  • Le lieu du snapshot d'une sortie programmée porte alwaysOpen, transmis à computeTimeline : un lieu always_open ne lève jamais hours_unknown, dans GET /me/planned comme dans /routes/:id/timeline.
  • Les snapshots déjà enregistrés restent lisibles : alwaysOpen absent vaut false (défaut à la lecture, sans migration destructive).

Critères d'acceptation

  • Test : une sortie programmée dont une étape est un lieu always_open sans horaires n'a pas de conflit hours_unknown dans GET /me/planned
  • Test : pour un même parcours et un même départ, GET /me/planned et GET /routes/:id/timeline?startsAt= rendent les mêmes heures et les mêmes conflits
  • Test : un snapshot enregistré sans alwaysOpen se lit sans erreur, avec alwaysOpen: false

Activity

  1. added this to the v0.4 milestone on Oct 19, 2026
  2. PaulThiberville commented on Oct 19, 2026

    @PaulThiberville
    CollaboratorAuthor

    🔨 Démarrage — plan : reprise du commit écrit par un agent opencode (GLM) sur issue/539-always-open-planned-timeline. Le snapshot d'une sortie programmée garde alwaysOpen (défaut false à la lecture, pas de migration) et le passe à computeTimeline. Relecture, puis tests HTTP des trois critères sur GET /v1/me/planned, et PR.

  3. modified the milestones: v0.4, v0.5 on Oct 19, 2026
  4. IlanAMG commented on Oct 19, 2026

    @IlanAMG
    Member

    Chef de projet (point du 19/10/2026) : jalon v0.4 → v0.5. Ticket découvert le 19/10, hors sprint : il ne s'ajoute pas au jalon en cours et va au jalon suivant (règle de périmètre du 13/10).

  5. modified the milestones: v0.5, v0.4 on Oct 19, 2026
  6. IlanAMG commented on Oct 19, 2026

    @IlanAMG
    Member

    Chef de projet (point du 19/10/2026) : jalon rétabli en v0.4, la PR #543 est déjà ouverte ; le déplacement en v0.5 fait quelques minutes plus tôt est annulé. Le ticket est entré au jalon en cours le jour de sa découverte : écart à la règle de périmètre signalé à Ilan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions