Decide client delivery boundaries and acceptance criteria #9

Activity

1. CasperEngl

   added

   wayfinder:grillingDecision requiring discussion with the developerDecision requiring discussion with the developer

   on Sep 9, 2026
2. CasperEngl

   added a parent issue on Sep 9, 2026

   • Plan inline chat annotations for T3 Code #2
3. CasperEngl

   marked this as blocked by 5 issues on Sep 9, 2026

   • Decide selection and annotation placement #4
   • Decide annotation identity and source changes #5
   • Decide draft ownership and submission #6
   • Decide agent context and reply association #7
   • Decide history and rewind semantics #8
4. CasperEngl commented on Sep 10, 2026

   

   CasperEngl

   on Sep 10, 2026

   OwnerAuthor

   More actions

   Existing-feature preservation audit

   CasperEngl's latest requirement is that the new flow improves authoring inside T3 rather than replacing it with a reduced-capability app. The consolidated decisions distinguish approved behavior from unresolved integration work.

   Current result: the ordinary app is still separate and available, but the prototype does not have feature parity and must not replace it. This audit is an input to acceptance criteria, not a resolution of #9 or approval of a new production architecture.

   Keep the existing owners and behaviors

   Capability	Existing owner / required integration	Current prototype status
   General context and annotation editing	The real ComposerPromptEditor: text selection, undo/redo, IME handling, inline-token editing, plain-text/mention paste, composer appearance preferences	Both prototype textareas now use the actual editor in separate editing islands, with explicit accessible names and a boundary-only caret bridge. This does not import all ChatComposer features.
   User/assistant content	ChatMarkdown and UserMessageBody: Markdown structure, code, tables/copy, task lists, links, workspace images, file/editor/preview actions, skills and terminal/review context	Full renderer reuse remains incomplete. The code-block shell/highlighter are real; flat-text slicing and custom spans still own the prototype source rendering. Do not claim this supports all rich content.
   Tools, diffs, plans, task/subagent/status rows	MessagesTimeline leaf renderers, PlainWorkEntryRow, FileDiff, proposed-plan and activity components	Production tool/diff renderers have not yet replaced the samples. Pierre uses shadow DOM and native line annotations; document Range traversal is not a compatible adapter by itself.
   Composer context types	Images and their upload/retry/remove states, file mentions, terminal contexts, element contexts, existing preview annotations, existing file-review comments	Not wired into prototype submissions. New discussion annotations must join these inputs, not replace them or coerce them into an unrelated existing type.
   Commands and provider controls	Slash commands, $ skills, path search, model/effort/context choices, runtime permissions, plan/build controls, context-window usage/compact	Still owned by the normal composer. Importing the text editor does not recreate the surrounding menus or provider state.
   Send lifecycle	ChatComposer validation and ChatView.onSend: max length, connection/provider readiness, in-flight guards, uploads, foreground/background creation, active-turn handling, interrupt, plan follow-up and provider-native commands	Fake in-memory batch submission only. Must use the existing send path and capability decisions for send/steer/queue, not a second pipeline. Failure must preserve the complete draft and attachment state.
   Drafts and history	Existing composer draft store, stash/task features, new-thread/worktree choices, thread actions, rewind/restore and checkpoints	Prototype drafts reset on reload. Durable annotations and their interaction with discard/rewind remain #5, #6 and #8.
   Terminal	Existing drawer, PTY/session lifecycle, selection/copy/paste, links, add-terminal-context, per-thread/environment identity	Real independent inline terminals work; the drawer is not replaced. Inline add-terminal-context is still a no-op, so terminal feature parity is not complete. ! now triggers only from an empty context so normal exclamation marks survive.
   Shell/navigation/source control	Sidebar/thread navigation, command palette/keybindings, header, panels, Git/worktree actions, file/browser previews and existing annotations	Normal routes keep these. The prototype sits inside the shell but is not a full ChatView alternative. Preserve all entry points, not only chat-view buttons.
   Providers	Codex, Claude, Cursor, Grok, OpenCode, plus existing configured-instance capabilities	No provider delivery has been implemented or exercised. Fake Codex fixture metadata is not proof of provider support. Shared serialization/capability decisions remain #7.
   Connections and clients	Environment-scoped IDs, local and hosted web, desktop IPC, native mobile navigation/editor, remote/relay/tunnel, reconnect, multi-device and multi-environment state	This pass checked one isolated local web environment. No desktop-native, iOS, Android, remote/tunnel, multi-device or reconnect parity claim. Separate delivery tasks remain required.
   Performance and accessibility	Production virtualization and scroll anchoring; keyboard/control focus, touch actions, assistive technology, mixed selection, streaming/reflow and source status	Small unvirtualized fixture only. Keep the real timeline's performance behavior when integrating. No large-history or native IME/touch-selection proof yet.

   Concrete conflict requiring a decision in #4

   The earlier no Send button choice conflicts with mobile-width composer rules. Reproduced at 390px: Enter added a newline, no submission occurred, and the submission area had zero buttons. The shared helper intentionally returns no submission intent for mobile Enter, including modifier Enter. This is an existing limitation of the prototype, not a regression in the normal mobile app.

   Recommendation awaiting CasperEngl: keep the button-free desktop authoring layout, but retain an existing accessible Send action for touch/mobile. Do not "fix" this by making mobile Enter send unexpectedly. All other composer controls need to remain reachable as part of the improved flow.

   Recommended integration boundary, not yet a resolved architecture

   Keep ChatView / ChatComposer responsible for the actual feature flow, and reuse production message/work renderers. Add narrowly scoped annotation/selection integration at those renderers. Do not grow a parallel mini-app, split raw Markdown to simulate rich rendering, mutate React-owned text nodes, or give the whole transcript to Lexical as editable content. Use Pierre's line-annotation API for diff placement; mixed shadow-DOM/document selection still needs an explicit design and proof.

   Source references at the audited revision:

   • ChatComposer and its draft/control integration
   • Current send pipeline
   • User message rendering
   • Tool rendering
   • Shared Enter behavior

   Verification this pass

   • 171 focused tests passed across the real prompt editor, submission-key logic, composer submission validation, Markdown, terminal surface, message timeline and scroll anchoring. Added tests for named annotation/context editors and unchanged default naming for existing callers.
   • Targeted lint, formatting and whitespace checks passed. Web typecheck reports only the same 11 pre-existing errors in the unrelated providerRefreshFeedback files.
   • Browser: real annotation/context editor, first-character preservation, exact source preservation and zero upward movement for prose/code, empty-blur removal, comments-only submission, Shift+Enter, clearing/refocusing after submission, undo/redo, boundary navigation and Mod+Down.
   • Browser: ordinary punctuation remains editable; empty-context ! starts a terminal; startup focus, Escape/Enter re-entry, and deleting only that terminal worked. The terminal opened in this pass was closed through its own UI. Prior terminal-survives-submission evidence remains in the handoff; it was not rerun here.
   • Ordinary app smoke check in a separate tab: normal new-thread composer, slash/skill menu, populated existing thread, provider/runtime controls, panels and source-control actions remained present. No provider turn was sent. No browser page errors during this pass.
   • Reproduced the mobile-width Send-action gap above. Native mobile, full provider execution, persistence, long-history performance, and complete feature parity are not verified.

   No production rollout, schema change, provider change, issue closure, commit, or PR. No shipped-product documentation changed because the new flow is still an experiment. The isolated development instance is retained for iteration; credentials are not recorded here.
5. CasperEngl commented on Sep 10, 2026

   

   CasperEngl

   on Sep 10, 2026

   OwnerAuthor

   More actions

   Interaction resolution and remaining evidence gates

   Decide selection and annotation placement is resolved through CasperEngl's live approvals. Its closure settles requested behavior; it is not evidence that the prototype or production app implements every part of it.

   Keep the existing-feature preservation audit as the capability baseline. Do not infer feature parity from the real editor or terminal components, or from focused tests of those components.

   For the final specification, distinguish:

   • Decision evidence still needed: a feasible source/renderer mapping, owned by Decide annotation identity and source changes, and a supported integration path that preserves existing app capabilities. Unresolved feasibility cannot be hidden by an acceptance checklist; bring any required product tradeoff back to the interaction decision.
   • Integrated delivery proof still required: real Markdown/code/tool/diff behavior; first-character and IME input; vertical caret and selection boundaries; native touch/accessible annotation entry and mobile Send; same-passage/overlap handling; visible and editable annotations beside collapsed sources and explicit Show source; streaming/reflow without focus or reading-position jumps; terminal behavior; and the existing audit's feature, client, provider, connection-mode, recovery and performance coverage. Link the interaction contract for expected behavior rather than rewriting it here.

   Some older prototype paths have browser/test evidence in the linked interaction record. Production renderer reuse and the newly approved paths remain unverified. Native mobile, desktop-specific and remote/multi-device acceptance must not be claimed from a desktop browser viewport alone. No new code or verification was performed during this resolution session.

   These remain gates for their respective planning/delivery stages, not accepted first-version omissions. No new implementation task is being executed by this map.