# Feature — Le Screen   ·   Module : core (chat + search + suite)   ·   Statut : **construit**

> Cadré le 2026-08-11 avec le user, **construit et garni le 2026-08-12** (B2). **Remplace
> `panneau-sortie.md`**, dont le fichier subsiste en renvoi pour ne casser aucun lien.
> Deux noms meurent ici : « viewer de page » et « panneau de sortie ». Il n'y a plus que le Screen.
>
> **Trois des quatre moteurs sont branchés** : la page web (2026-08-06), le document éditable avec
> ses gabarits et ses images (B2, B7, B8), et le **schéma** (B1, 2026-08-15 — voir
> [`schemas.md`](schemas.md)). Reste le **PDF natif**, toujours hors périmètre.

## Intention

**Un seul endroit où quelque chose s'affiche à côté.** Une page web, un document, un schéma, un
PDF, un tableur un jour : c'est toujours le Screen qui sort. La forme ne change pas ; seul le
moteur de rendu change, et ce choix est à nous, en amont, invisible pour l'utilisateur.

Il n'ouvre pas « le lecteur de PDF » ni « l'éditeur ». Il ouvre le Screen, et le Screen sait quoi
faire de ce qu'on lui donne.

## Le principe, et tout en découle

> **Le Screen ne possède rien. Il projette.**
> Ce qui persiste, c'est la **source** — et le Screen se rouvre depuis elle.

Vérifié sur les quatre contenus connus :

| Contenu | Sa source | Ce que le Screen stocke |
|---|---|---|
| Schéma Mermaid | le bloc dans le message, déjà en base | **rien** |
| Page web | l'URL + le markdown dérivé, purgé avec le projet (tranché le 2026-08-07) | **rien** |
| Document | l'objet Document lui-même — c'est ça, un document | **rien** |
| Synthèse de recherche | la recherche enregistrée et son snapshot | **rien** |

Dans les quatre cas, **la persistance existait avant le Screen et sans lui.** Elle n'est donc pas
un chantier : il n'y a rien à écrire.

Le cas « sauvegarder un Mermaid » n'est pas une exception : quand l'utilisateur veut le garder, ce
n'est plus le Screen qui persiste, c'est un **Document qui naît**. La règle se fait à l'outil, pas
au contenant.

## Le Screen répond aussi — la prise

Le Screen n'est pas une vitrine. Ce qu'il affiche doit pouvoir être **désigné** et **modifié**
depuis le chat : je sélectionne un passage et je demande « reformule », le passage est remplacé ;
je dis « change le nom de la bulle *chien* en *chat* », le schéma se met à jour.

**C'est la symétrie du Screen, et elle est gratuite** : chaque moteur qu'on ajoute apporte une
**sortie** (afficher) *et* une **prise** (modifier). TipTap a un modèle de document avec des
positions, un schéma se modifie par sa source, un tableur aura son API. Le Screen, lui, ne change
pas.

Une page web fait exception, et c'est cohérent : elle est en lecture, donc désignable mais non
modifiable.

⚠️ **La difficulté n'est pas dans le Screen, elle est dans le tour de chat** — un tour de
modification doit rendre le texte de remplacement et rien d'autre, être annulable, et ne jamais
appliquer un résultat qui casserait le contenu. Ces contraintes vivent dans
[`dossier-projet.md`](dossier-projet.md), décision 7.

## Contraintes (non-négociables)

- **Un seul Screen. Remplacement. Pas d'onglets.** Les onglets servent à ne pas perdre ce qu'on a
  sous les yeux ; si tout se rouvre en un clic depuis sa source, il n'y a rien à perdre. On
  paierait un état à tenir, un titre par onglet, une fermeture individuelle, un nombre maximum et
  un mobile à 380 px, pour un problème que le principe ci-dessus dissout.
- ⚠️ **Chaque contenu doit avoir son bouton de réouverture, là où il est né.** C'est la condition
  de tout le reste : le rendu sous la réponse du chat, la source dans la liste de résultats, la
  page dans le projet, le document dans le Drive. **S'il manque quelque part, le remplacement
  redevient une perte et les onglets reviennent par la fenêtre.** C'est le point de vigilance de
  cette spec.
- **La forme est invariante.** Largeurs, en-tête, fermeture, plein écran en mobile : identiques
  quel que soit le contenu. Ce qui varie est à l'intérieur.
- **Le Screen reste ouvert quand on change d'outil.** Il ne coûte rien et ne perd rien : le fermer
  d'office serait une décision gratuite prise contre l'utilisateur — typiquement lire une page,
  puis aller la commenter dans le chat. **Il se ferme quand on le ferme.**
- **Le Screen ne stocke rien et ne modélise rien.** Il ne gouverne donc pas l'architecture. Ce qui
  la gouverne, ce sont les objets sources.
- **Le Screen ne s'affiche qu'avec un contenu.** Sinon on n'a pas livré un contenant à garnir, on a
  livré un trou.
- **Le choix du moteur de rendu est en amont, et invisible.** Aucune logique de rendu dans le
  Screen : il reçoit un contenu qui déclare **ce qu'il est**, et il aiguille.
- **« Screen » est notre mot, jamais affiché.** Le vocabulaire produit est en français (recherche
  enregistrée, projet, outils). Le nom vu par l'utilisateur reste à trouver — voir « Ouvert ».

### Une règle d'origine est tombée, et c'est déjà fait

`panneau-sortie.md` posait : *« les sources partent dehors, les productions restent dedans »*.
**Le viewer de page l'a dépassée le 2026-08-06** — une source s'ouvre désormais dans le Screen, et
c'est mieux. Ce qui reste vrai : un lien vers le site externe doit rester **atteignable**, parce
qu'aller à la source est un besoin réel. Ce n'est plus la destination par défaut, c'est une action.

## Périmètre

**Dans le périmètre**

- Le contenant et ses invariants (largeurs, en-tête, actions, fermeture, mobile).
- Le **contrat de déclaration** : un contenu arrive en disant ce qu'il est.
- L'aiguillage vers le moteur de rendu correspondant.
- Les **boutons de réouverture** aux quatre sources — c'est du travail réparti, pas du travail dans
  le Screen, et c'est la moitié de l'effort réel.
- Les quatre contenus connus : page web, document, schéma, PDF.

**Hors périmètre**

- **La persistance.** Elle appartient aux objets sources, qui existent déjà ou sont spécifiés
  ailleurs (`suite/suite.md` pour le Document et le Drive).
- **Les onglets et la comparaison côte à côte.** Le besoin de comparer est réel mais autre ; il
  n'est demandé nulle part aujourd'hui et se rouvrira le jour où il apparaîtra. **Ne pas le
  confondre avec les onglets**, qui répondaient, eux, à un faux problème.
- **L'édition.** Modifier implique sauvegarder, donc le Workspace. Voir `suite/suite.md`, phase 1.
  *TipTap est déjà installé en headless comme passerelle Markdown → DOCX ; il ne manque que la
  liaison React. L'affichage est proche, c'est la persistance qui est loin.*

## Pistes d'implémentation (indicatives)

- **La coque existe depuis le 2026-08-06** : `SidePanel`, trois paliers de largeur, partage 50/50,
  `outputPanelStore` qui porte le contenu, mobile en plein écran. Rien de tout cela n'est à
  reprendre.
- `styles/prose.css` donne déjà la mise en forme de contenu, partagée avec le viewer.
- Conséquence de plan : Mermaid, TipTap, la page web et le PDF natif **cessent d'être quatre
  chantiers d'affichage**. Ce sont quatre moteurs branchés derrière une porte déjà ouverte. Chacun
  devient petit, aucun ne redessine l'écran.

  ✅ **Vérifié à l'usage.** TipTap est entré le 2026-08-12, Mermaid le 2026-08-15 — et **aucun des
  deux n'a redessiné l'écran** : le second est même arrivé comme une vue de nœud à l'intérieur du
  premier. La prédiction tenait.

## Critères de « fait »

1. Les quatre contenus s'affichent dans le **même** contenant : mêmes largeurs, même en-tête, même
   fermeture, même comportement mobile.
2. Chaque contenu affiché a, **à sa source**, un bouton qui le rouvre.
3. Ouvrir un second contenu remplace le premier **sans rien perdre** : le premier se rouvre en un
   clic depuis sa source.
4. Changer d'outil ne ferme pas le Screen.
5. **Rien de ce qui s'affiche n'est écrit en base du fait de son affichage.**
6. Ouvrir le Screen ne fait pas quitter l'écran courant et n'en perd pas l'état ; le fermer restitue
   la largeur complète.
7. Une sélection dans le Screen est adressable depuis le chat, et le résultat revient **dans le
   Screen**, pas dans le fil.

## Ouvert

- **Le nom vu par l'utilisateur.** « Screen » est interne. Le contenant a-t-il seulement besoin
  d'être nommé dans l'interface ?
- **La comparaison côte à côte** — à rouvrir si le besoin apparaît, jamais avant.
- **Un contenu sans source réouvrable, ça existe ?** Si oui, il fait exception au principe et il
  faut le savoir avant, pas après.

## Décisions liées : #0006 (une recherche = une requête)