Skip to content

Add workspace review, agent attention, and delivery workflows #128

Closed
Closed
Add workspace review, agent attention, and delivery workflows#128
Labels
enhancementNew feature or request
Milestone
Agent workspaces and review cockpit

Description

@benfavre
benfavre
opened on Aug 27, 2026

Parent epic: https://github.com/bext-stack/automonique/issues/163
Depends on: the ShellDeck workspace-navigation issue and https://github.com/bext-stack/automonique/issues/168

Outcome

Keep review and agent attention inside the active workspace, with notifications that jump to the exact originating pane.

Work

  • Add combined staged/unstaged/untracked review with file staging and conflict state. (Hunk staging is not representable in the review contract — split to Le staging par hunk n'est pas représentable dans le contrat de revue #163.)
  • Render safe previews for supported text, image, and HTML changes.
  • Persist line-anchored comments and batch-send selected notes to the authorized session.
  • Render checks, pull-request/review status, merge readiness, and delivery state with authority/freshness.
  • Add structured Needs You, Working, Blocked, Done, idle, unread, and nested-agent projections.
  • Add chronological activity and desktop notifications that deep-link to workspace/session/pane.
  • Use typed, revision-bound actions with previews, receipts, and ambiguous-write reconciliation.
  • Add SDUC/SDTEST coverage and cross-platform CI gates.

Acceptance

  • Review comments and delivery mutations execute once and remain actor-attributed.
  • Provider-session control cannot silently grant git, CI, or pull-request mutation authority.
  • An attention item always identifies and opens its authoritative workspace context.

Activity

  1. benfavre
    added this to the Agent workspaces and review cockpit milestone on Aug 27, 2026
  2. benfavre
    added
    enhancementNew feature or request
    on Aug 27, 2026

  3. benfavre commented on Aug 27, 2026

    @benfavre
    benfavre
    on Aug 27, 2026
    OwnerAuthor

    Foundation merged through PR #133. It adds the bounded, authority-fenced review, attention, delivery, draft, receipt, and recovery core; exact workspace-keyed attention navigation; and the SDUC/SDTEST plus Linux, macOS, and Windows CI coverage. The issue remains open: GPUI review/previews/comments/activity, production git/CI/PR adapters, notifications, and native crash/release acceptance are still required.

  4. benfavre commented on Aug 28, 2026

    @benfavre
    benfavre
    on Aug 28, 2026
    OwnerAuthor

    Merged PR #137 at the reviewed head. The workspace lifecycle now supplies the hardened cancellation, recovery, and cross-platform seams needed by review/attention work, and its SDUC/SDTEST gates passed on Linux, macOS, and Windows. This issue remains open because canonical review projections plus Git/CI/PR/notification adapters and mutation receipts are still being implemented.

  5. benfavre commented on Aug 28, 2026

    @benfavre
    benfavre
    on Aug 28, 2026
    OwnerAuthor

    Merged PR #138 at the independently reviewed and twice-repaired exact head. ShellDeck now negotiates and renders the canonical typed Platform v2 review projection read-only from an exactly reconciled catalog mapping, preserving attention source revisions plus review/check/PR/delivery freshness and authority, diff/preview/conflict/comment/proposal semantics. CI passed on Linux, macOS, and Windows with security/licence gates green. Review found and fixed both workspace-switch and same-ID cross-server/credential attribution races before merge. The issue remains open for the exhaustive shared render corpus, Git/CI/PR/notification action adapters, receipts, and deep-link acceptance.

  6. benfavre commented on Aug 28, 2026

    @benfavre
    benfavre
    on Aug 28, 2026
    OwnerAuthor

    PR #141 merged to main at 0cdab1a after Linux, macOS ARM, and Windows CI passed. It adds bounded canonical file/hunk/conflict/comment projections and attention chronology, plus confirmation previews and exactly-once, revision-bound AddComment/ApproveReview dispatch. Ambiguous outcomes remain pinned to the original workspace/revision/hunk/connection and reconcile only by the original idempotency key; switching workspaces neither replays nor blocks unrelated targets. Git/CI/PR/delivery and provider-session authority remain inert rather than inferred. The broad checklist items stay open for real file/hunk staging, safe content previews, batch send-to-agent, full nested-agent/desktop notification deep links, and external effect adapters.

  7. benfavre commented on Aug 28, 2026

    @benfavre
    benfavre
    on Aug 28, 2026
    OwnerAuthor

    Merged the exact review-effects client foundation in PR #144 (merge 865afe7). This adds fail-closed typed previews for every review action; shared exact authority/freshness/state admission; localized EN/FR confirmations naming the complete project/workspace/snapshot/action coordinates; snapshot-bound selection clearing; and SDUC-495 / SDTEST-1791 / SDTEST-1792 coverage. Linux, macOS, and Windows CI passed. The typed revision-bound action checklist item is complete. This issue remains open for the still-unimplemented combined review renderer, attention/deep-link workflow, and production server delivery/provider adapters and live acceptance.

  8. benfavre commented on Aug 28, 2026

    @benfavre
    benfavre
    on Aug 28, 2026
    OwnerAuthor

    Merged the exact local attention-navigation slice through PR #149 (df0294a; reviewed tree 2797d57).

    Completed and verified:

    • per-workspace typed attention board with Needs You, Working, Blocked, Done, unread, and bounded nested-agent paths;
    • captured-revision activation that re-resolves the current workspace/pane/tab and fails closed on stale, missing, foreign, duplicate, or mismatched bindings;
    • exact native tab selection before consuming the matching unread revision;
    • the race where the active tab changes after observation still opens the originally captured authoritative tab;
    • authority remains separated: provider-session observation cannot grant Git, CI, pull-request, shell, or filesystem mutation authority.

    Validation passed 365 core tests (5 ignored), 163 UI tests, docs, Clippy with warnings denied, formatting/diff checks, focused SDTEST-1810/1811, and all Linux/macOS/Windows CI jobs.

    The issue remains open: production has no authoritative attention snapshot producer yet, so this merge does not claim live pane/session deep-link completion. The next cross-repository contract must carry a source-scoped opaque item/revision and exact Platform session coordinate; ShellDeck must resolve that to one current local binding rather than infer from chronology or the active tab.

  9. benfavre commented on Aug 28, 2026

    @benfavre
    benfavre
    on Aug 28, 2026
    OwnerAuthor

    Core attention custody landed in PR #153 and was merged at exact reviewed head acce36052ac446bf0000ad3388466dfea394fb66 (merge 2315e9af62069637ed1da08d78da08e32a5b550b).

    This slice adds the bounded authoritative attention projection, explicit authenticated baseline/resync semantics, persistent revision custody, stable collision-safe identifiers, atomic inventory removal/re-add handling, multiprocess notification reservation, and fail-closed cross-platform storage boundaries. Validation passed on Linux plus the repository's macOS and Windows CI, licenses/bans/sources, and RustSec.

    The issue remains open: UI activation, exact workspace/session/pane navigation, notification delivery/deep links, and the remaining review workflow checklist are still being implemented.

  10. benfavre
    added a commit that references this issue on Aug 29, 2026

    Merge pull request #159 from benfavre/fix/review-staging-previews-128

    c177829

  11. benfavre commented on Aug 29, 2026

    @benfavre
    benfavre
    on Aug 29, 2026
    OwnerAuthor

    Point d'étape — ce qui est livré, ce qui reste bloqué côté serveur

    Livré (PR #159, fusionnée) :

    • La vue combinée indexé / non indexé / non suivi avec état de conflit. C'était une projection en lecture : ReviewFile porte déjà worktree, conflict, les hunks et les métadonnées d'aperçu. Un fichier partiellement indexé apparaît des deux côtés et est signalé ; un conflit non résolu est listé uniquement comme conflit, comme git le rapporte.
    • Les aperçus sûrs : aucun pixel décodé, aucun HTML interprété, bornes du client appliquées aux revendications du serveur. Au passage, le texte sûr retire les treize scalaires invisibles de réordonnancement que la borne char::is_control du protocole ne capture pas — un aperçu de hunk « sans caractères de contrôle » pouvait repeindre une ligne de diff (trojan source).

    Bloqué, et pourquoi c'est structurel :

    • Le staging fichier n'a aucune capacité serveur qui pourrait le clôturer exactement une fois. ReviewCapabilities ne porte que rerunnable_checks, et l'invariant du code impose qu'une confirmation ne puisse accompagner qu'un rerun : Stage / Unstage / Commit / ResolveConflict ne peuvent structurellement pas en porter une. Même dispatchées, rien ne corrélerait le reçu. La surface affiche l'absence de barrière au lieu d'un contrôle.
    • Le staging au niveau du hunk n'est pas représentable : les propositions du protocole listent des identifiants de fichiers, il n'existe aucune granularité hunk dans le contrat. L'item demande donc quelque chose que le contrat ne peut pas exprimer aujourd'hui.

    Déblocage : une ReviewStageCapability sur ReviewCapabilities (identifiant de proposition, révisions attendues, autorité git, digests de confirmation et de corrélation) plus l'assouplissement de l'invariant de confirmation, dans bext-stack/automonique. Le magasin de custody durable gère déjà ces actions génériquement.

    Aucune capacité n'a été fabriquée et aucune mutation git côté client n'a été ajoutée.

    L'autre moitié (notes ancrées, barrière de custody, activité chronologique) suit en PR #160.

  12. benfavre commented on Aug 29, 2026

    @benfavre
    benfavre
    on Aug 29, 2026
    OwnerAuthor

    PR #160 fusionnée — état final des deux items restants

    Livré dans #160 :

    • Notes ancrées persistées. Chaque note retient fichier, hunk, côté, ligne et la révision de snapshot contre laquelle elle a été écrite. Un snapshot dépassé rend la note explicitement périmée au lieu de la ré-ancrer silencieusement ailleurs.
    • Activité chronologique, ordonnée sur l'horodatage faisant autorité — jamais sur l'ordre d'arrivée des sondages. Les lignes ne portent que le jeton d'activation, donc le résolveur de Activate the authoritative attention board in Workspace and Fleet #156 reste l'unique résolveur.
    • La barrière de custody couvre enfin les trois mutations exposées. C'était le vrai défaut derrière l'item d'acceptation : Add confirmed check-rerun custody #155 n'avait câblé la custody que pour le rerun confirmé, alors que AddComment et ApproveReview sont les deux mutations que Fleet expose réellement. Elles partaient sans aucune trace durable — un redémarrage entre le POST et le reçu rendait un commentaire posté indiscernable d'un commentaire jamais parti, et re-préparer frappait une nouvelle clé d'idempotence, donc un doublon serveur. Le format disque comprenait déjà ces actions ; personne ne l'appelait avec elles.

    Les deux items restent décochés, et pour une seule et même raison.

    ReviewCapabilities n'annonce que rerunnable_checks. Aucune capacité de staging, aucune capacité d'envoi groupé — donc aucun digest de confirmation ni de corrélation de reçu pour l'un ou l'autre. Les deux moitiés de ce ticket sont arrivées à cette conclusion indépendamment, par des chemins opposés : une seule lacune du contrat, deux contrôles non exposés.

    Ce qui est livré de ces deux items :

    • la vue combinée indexé / non indexé / non suivi avec état de conflit (seul le staging manque) ;
    • la persistance des notes ancrées et leur sélection (seul l'envoi groupé manque).

    Ce qui manque n'est pas contournable côté client : sans digest frappé par le serveur, une écriture ne pourrait partir que non confirmée et non corrélée, et un résultat ambigu ne serait plus réconciliable que par une recherche de clé non corrélée — exactement ce que la voie du rerun existe pour éviter. S'y ajoute, pour le staging, que la granularité hunk n'est pas représentable : les propositions du protocole listent des identifiants de fichiers.

    Déblocage, dans bext-stack/automonique : une capacité de staging et une capacité d'envoi groupé sur ReviewCapabilities, chacune avec ses deux digests, plus l'assouplissement de l'invariant qui réserve aujourd'hui la confirmation au seul rerun. Le magasin de custody durable gère déjà ces actions génériquement.

  13. benfavre commented on Aug 29, 2026

    @benfavre
    benfavre
    on Aug 29, 2026
    OwnerAuthor

    Envoi groupé livré (PR #161) — un seul item reste

    La capacité serveur a atterri dans bext-stack/automonique PR #221 (voie non confirmée : ni digest de confirmation, ni corrélation de reçu, délibérément — la cible est propriété du registre et jamais sur le fil, la révision est clôturée deux fois côté serveur, et l'exactement-une-fois tombe de la machine à états). ShellDeck la consomme désormais.

    Précision de vocabulaire sur cet item. Les notes sont des brouillons locaux sans identifiant serveur : elles ne peuvent pas être livrées telles quelles. Ce qui part, ce sont les commentaires sélectionnés, l'annonce serveur nommant leurs identifiants ; la sélection de notes sert de marqueur « quels brouillons préparer ». L'item est coché sur cette lecture.

    Trois trouvailles qui valent d'être consignées

    1. matches_capabilities renvoyait true inconditionnellement pour toute action non confirmée. La fonction ne testait réellement que le rerun et retombait sur « pas de confirmation, donc valide » pour tout le reste. Sans correctif, le cas de la liste périmée aurait atteint le serveur, et toute la discipline « relire après règlement » aurait été décorative côté client.

    2. La custody ne pouvait pas enregistrer cette action du tout. Le format disque ne couvrait que AddComment, ApproveReview et RerunCheck : la préparation aurait renvoyé « action non supportée » et l'envoi serait mort à la barrière. La note de PR Persist anchored review notes, fence every review mutation, and order attention chronologically #160 disant que « le format comprenait déjà ces actions » était vraie pour les deux qu'elle nommait, pas pour celle-ci.

    3. Bug latent d'ordonnancement. L'ancien constructeur assemblait le lot dans l'ordre de l'appelant alors que le protocole exige un tri strict par identifiant. Parcourir l'annonce — déjà triée par le serveur — corrige ça structurellement.

    Les tests ont été vérifiés par mutation, et la première version de l'un d'eux a survécu à la mutation censée le faire tomber : il n'exerçait que la projection, pas le chemin emprunté par l'aperçu d'action. Comblé.

    Ce qui reste

    Le staging fichier et hunk. PR #221 a délibérément livré aucune capacité de staging, et pour une raison précise : son digest devrait s'engager sur l'oid de HEAD et l'état de l'index, qu'aucune projection ne porte — HEAD et l'index bougent sous le démon entre l'annonce et l'exécution, et la révision de snapshot ne suit que ce que la projection a observé. Deviner ce jeu de champs produirait un digest qui ressemble à une barrière sans rien retenir.

    S'y ajoute que la granularité hunk n'est pas représentable : les propositions du protocole listent des identifiants de fichiers.

    Le déblocage passe donc par une projection amont portant l'état du worktree, puis sa capacité — et le raisonnement est désormais consigné dans les épingles côté automonique, qui couvrent les quatre actions de staging plutôt que la seule.

  14. benfavre commented on Aug 29, 2026

    @benfavre
    benfavre
    on Aug 29, 2026
    OwnerAuthor

    Fermée. Tous les items sont livrés, avec une réserve nommée plutôt que dissimulée : le staging par hunk n'est pas représentable dans le contrat de revue et part en suivi séparé — #163.

    Ce qu'il aura fallu

    Cet item n'était pas bloqué par du code manquant ici, mais par une lacune unique du contrat serveur : ReviewCapabilities n'annonçait que les reruns de check. Sans digest frappé par le serveur, une écriture ne pouvait partir que non confirmée et non corrélée — ce que ce ticket interdit. Livré en amont aujourd'hui dans bext-stack/automonique : #221 le contrat, #225 l'adaptateur d'écriture git.

    Le staging par hunk reste hors de portée pour une raison de fond, pas de calendrier : les propositions du protocole portent des identifiants de fichiers, et un numéro de hunk est une position dans un diff, pas une identité — il se déplace dès que le fichier bouge. Un digest de staging par hunk ressemblerait à une barrière sans rien retenir. #163 chiffre ce qui manque.

    Défauts trouvés en chemin, tous de la même famille

    Le motif dominant de ce ticket : une règle du contrat recopiée localement, qui dérive quand le contrat grandit. Aucun n'aurait échoué bruyamment.

    • La custody ne couvrait que le rerun confirmé, alors que AddComment et ApproveReview sont les deux mutations que Fleet expose réellement — elles partaient sans trace durable.
    • matches_capabilities renvoyait true inconditionnellement pour toute action non confirmée : le cas de la liste périmée aurait atteint le serveur.
    • Le garde de confirmation de review_action restait figé sur « seul le rerun », alors que le contrat en nomme désormais huit — merge_pull_request frappait déjà des aperçus que le transport ne peut plus encoder.
    • Le format disque de custody a dû être étendu deux fois — pour l'envoi groupé, puis pour les familles de staging — après avoir été supposé complet à chaque fois.
    • Les aperçus laissaient passer les treize scalaires invisibles de réordonnancement que la borne char::is_control du protocole ne capture pas : un aperçu de hunk « sans caractères de contrôle » pouvait repeindre une ligne de diff (trojan source).

    Ce qui fence le résultat

    Les contrôles ne sont rendus que là où le serveur a frappé le créneau : un droit de commit retenu se traduit par l'absence du contrôle, pas par un bouton grisé. Le test le démontre plutôt que de l'affirmer — indexation et désindexation vont jusqu'à un aperçu confirmé dispatchable pendant que le commit est absent, puis le droit est installé et le troisième contrôle apparaît sans changement de code. Vérifié par mutation.

    Toutes les mutations exposées passent par la barrière de custody durable, et la préparation est refusée d'emblée si le magasin est indisponible.

  15. benfavre
    closed this as completedon Aug 29, 2026
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

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions