kandev/docs/specs/office-task-content-editing/spec.md

status, created, owner

status	created	owner
specified	2026-08-19	kandev

Office Task Content Editing

Why

The Office task detail page (/office/tasks/[id], simple pane) renders the task title and description as static text. Every other property on the page (status, priority, assignee, project, parent, blockers, reviewers, approvers, labels) is editable inline. The two fields that carry the most meaning are the two a user cannot change.

The description is not decoration: it is the brief the assigned agent works from. A typo in the title, a missing constraint in the brief, or a scope note that arrived after the task was filed currently has exactly one remedy: leave the Office UI, open /t/<id>, and edit from the Kanban surface. Users read the absence as a bug. It is not: docs/specs/office/tasks.md:58 enumerates the editable properties and omits both fields, and the shipped code implements that list faithfully. This is a spec gap, and this document closes it.

Nothing in the backend blocks it. PATCH /api/v1/tasks/:id has accepted title and description since before Office existed, both surfaces read the same tasks row, and the resulting task.updated event already drives the Office detail page's live refresh.

What

A. Scope of the affordance

• The title and description of a task are editable in place on the Office task detail page's simple pane. No dialog, no navigation, no separate edit mode for the page as a whole.
• The affordance is available on every task the detail page can render, in every task status (including done and cancelled) and in every session state (including RUNNING). No new permission, ownership, or lifecycle gate is introduced. This matches the sidebar property pickers, which are likewise ungated.
• Archived tasks are not a special case here. The Kanban title editor (apps/web/components/task/task-top-bar-title.tsx) gates renaming on an isArchived prop, and parts of that component are reused for the title editor. That gate is deliberately NOT ported. The Office detail page does not render an archived state, does not receive an equivalent flag, and Service.UpdateTask enforces no archived precondition of its own, so porting the gate would introduce a condition that can never be true and would read as dead code. AC-30 and AC-47 govern.
• Only the simple pane is in scope. The advanced / dockview mode is unchanged.

B. Title editing (inline, Enter to commit)

• The title renders as a text element that the user activates by double-click, or by focusing it and pressing Enter. Activation replaces it with a single-line text input seeded with the current title, focused, with its contents selected.
• Enter commits. Escape cancels and discards the draft. Blur cancels and discards the draft.
• The title baseline. When the title editor opens it captures the displayed title at that moment as its frozen baseline, frozen for the lifetime of the editor. Wherever this document says "the stored title" while a title editor is open (AC-4's restore target, AC-8's equality test) it means that frozen baseline, never a canonical value that arrived afterwards. This is the same construct section C defines for the description and it exists for the same reason: while the editor is open the displayed title is guarded (section E), so a remote edit must not silently change what Escape restores or what counts as "unchanged". The canonical value that arrived meanwhile is not lost. It is applied when the editor closes, under the deferred-apply rule in section E. AC-51 governs.
• Commit is optimistic: the new title renders immediately, the request is issued, and on failure the previous title is restored and the error surfaces as a toast. Which value "the previous title" means when commits overlap is defined in section F under "Rollback ordering".
• The value that is sent and the value that is optimistically rendered are both the whitespace-trimmed draft, so the visible title always equals the value the server will persist. The server trims too; the client trims first so the two never disagree, even briefly.
• The input is hard-clamped to 60 characters as the user types, counted the same way the backend counts (Unicode code points, TaskTitleMaxLength = 60 in apps/backend/internal/task/service/task_title.go). The caret must not jump to the end of the field when a keystroke is clamped away.
• Paste is clamped identically to typing: the pasted text is inserted at the caret, the result is clamped to the first 60 code points, and the caret stays at the end of the inserted run (or at the clamp boundary when the insertion is cut short). Paste is not a separate code path with separate truncation rules.
• A commit whose trimmed draft is empty is refused client-side: the editor stays open, the field is marked invalid, and no request is issued. The draft is never silently discarded.
• A commit whose trimmed draft equals the current title issues no request and closes the editor.
• IME composition must not commit. An Enter that the IME is using to accept a candidate is consumed by the IME, not by the editor.

C. Description editing (explicit Save and Cancel)

• The description renders as static text that the user activates by clicking it. Activation replaces it with a multi-line textarea seeded with the current description, focused, caret at the end.
• When the task has no description, the page renders a persistent placeholder affordance in the description's position that activates the same editor. An empty description must never leave the user with nothing to click.
• "No description" is defined as: the stored description, after trimming, is the empty string. This single definition covers null, "", and a field omitted from the DTO (the Office task DTO serialises description with omitempty, so all three reach the client as the same absence). There is no fourth state and no visible difference between them.
• The editor baseline. When the editor opens it captures the current stored description as its baseline, and that baseline is frozen for the lifetime of the editor. Every draft-versus-stored comparison in this document (Save enabled/disabled, Cancel confirm/no-confirm, Escape inert/closing) compares the trimmed draft against the frozen baseline, never against a value that may have changed underneath. A successful save replaces the baseline with the value that was saved. Nothing else replaces it. The rationale is in section F under "Late-arriving refresh": without a frozen baseline, a remote edit by another client silently flips Save, Cancel, and Escape behaviour while the user is typing, with no action of their own.
• Comparisons use the trimmed draft, and the value sent is the trimmed draft. A whitespace-only draft is therefore equal to an empty one, so a whitespace-only edit on an empty description leaves Save disabled rather than issuing a save that the server would silently reduce to a no-op.
• The editor commits only on an explicit Save. Cancel discards. Blur does not commit and does not close the editor: the draft survives clicking elsewhere on the page.
• Escape discards the draft and closes the editor when the draft is unchanged from the baseline. When the draft is changed, Escape does nothing; the user must choose Save or Cancel.
• Cancel with a changed draft requires a confirmation before the draft is discarded. Cancel with an unchanged draft closes immediately with no prompt.
• Save is disabled while the trimmed draft equals the baseline, and while a save is in flight.
• Save is not optimistic: the editor stays open and shows a saving state until the request resolves. The non-optimism is end to end, not just on this page: the description's Office task store patch, which drives card previews in list and board views, is also applied only on success (section E, AC-56). A card preview that updated before the save resolved would contradict this bullet on a different surface. On failure the editor stays open with the draft intact and the error surfaces as a toast, so a rejected save never destroys typing.
• While a save is in flight the textarea stays editable; Save and Cancel are both disabled and Escape does nothing. Disabling the textarea instead would silently swallow keystrokes the user has already begun typing.
• On a successful save, if the current trimmed draft still equals the text that was submitted, the editor closes and the saved value renders. If the user edited the draft while the save was in flight, the editor stays open with the newer draft intact and the baseline becomes the value that was just saved, so Save re-enables for the newer text. A successful save must never discard typing that the user did after pressing it. This is the same principle as the failure path, applied to the success path.
• The description is plain text, rendered with preserved whitespace. This feature introduces no Markdown rendering and no rich-text editing.
• There is no length limit on the description, client-side or server-side.

Why the two fields differ. The title is one line, bounded at 60 characters, and cheap to retype if a commit is lost; optimistic-with-discard matches the pickers and the existing Kanban rename. The description is unbounded prose that is also the agent's brief: Kandev stores no description version history, so a save that fires by accident, or a draft dropped on blur, is unrecoverable. The industry split follows exactly that line. Linear and Notion autosave and have undo; Jira and GitHub use explicit buttons and do not. Kandev is in the second group. project-header.tsx already gates a Save affordance on a dirty long-form Office textarea, which is the precedent for requiring an explicit commit; it is not a precedent for this feature's control layout, which section H specifies directly.

D. What an edit does NOT do

• A title or description edit does not wake, interrupt, or re-prompt the assigned agent, and does not queue a run. Verified: Service.UpdateTask publishes task.updated (service_tasks.go:1607); the only Office subscriber for that event is handleTaskUpdated (internal/office/service/event_subscribers.go:749), which reads assignee_agent_profile_id off the payload; publishTaskEventNow (service_events.go:370-436) never puts that field on a task.updated payload. With an empty profile id and fallbackToStoredRunner = false, queueTaskAssignedRun returns without queuing. Note that TaskUpdatedData declares that field even though this publisher never sets it, so the invariant is one added line away from breaking. AC-31 is therefore a tested contract, not a standing code-reading.
• Consequently, a running agent continues on the brief it was launched with. An edited description is picked up at the agent's next wakeup, produced by the existing triggers (a comment, an assignment change, a status change), not by the edit.
• Because this surprises users, the description editor shows a non-blocking inline note while at least one session on the task is in state RUNNING, stating that the change applies at the agent's next wakeup. The note never blocks Save.
• An edit does not change task status, does not move the task between workflow steps, and records no approval decision.

E. Persistence and live update

• Both fields are written through the existing PATCH /api/v1/tasks/:id endpoint (frontend: updateTask() in apps/web/lib/api/domains/kanban-api.ts). The Office endpoint PATCH /api/v1/office/tasks/:id is not extended, and its documented field list in docs/specs/office/tasks.md:229 remains correct.
• The request carries only the field being edited. A title commit sends { title }; a description save sends { description }.
• The server trims leading and trailing whitespace from both fields before persisting (task_http_handlers.go, httpUpdateTask). The client trims before sending as well (sections B and C), so the rendered value equals the stored value at every moment, not merely after a round-trip.
• After a successful write the backend publishes task.updated, which the Office WS broadcaster re-emits as office.task.updated, which triggers triggerRefetch("task:<id>") and re-fetches the canonical task DTO. Other open clients converge without polling. No new event, subject, or subscriber is introduced.
• Canonical value versus displayed value. These are two different things and the distinction carries the whole of this section. The canonical value of a field is the value this client last learned the server holds. The displayed value is what renders on the page, what seeds an editor, and what the Office task store entry carries for list and board cards. They are usually equal. They diverge exactly while a local edit is in flight or an editor is open, and the rules below say how they re-converge. Nothing in this feature ever discards a canonical value in order to protect a draft; it defers applying it.
• What records a canonical value: the complete list. Exactly three events record a canonical value for a field, and nothing else does.
  1. The initial task load for the page records both fields (AC-59).
  2. A refetch resolving, unless the response is discarded by one of the two ordering rules below (AC-49).
  3. A successful write resolving, which records the value that request persisted for the field it wrote, read from the response body. updateTask() already returns the updated task (apps/web/lib/api/domains/kanban-api.ts), so this costs no extra request. The recording happens before the write releases that field's guard (AC-58). Every recording of description is normalised to the empty string first. undefined, null, and a field omitted from the payload all record as "". This is not a tidiness rule and it is not optional: the two sources genuinely disagree in their types. The Office task DTO declares description optional (OfficeTask in apps/web/lib/state/slices/office/types.ts, and the Go side serialises it with omitempty), so a load or refetch recording can carry undefined; a write response carries Task.description, which is a required string (apps/web/lib/types/http.ts), so it records "". Without normalisation those two are unequal, AC-50 applies a canonical value "if the two differ", and every guard release on a task with no description would fire a spurious apply forever. Normalising at the recording site makes the canonical value, the displayed value and the store entry use the one definition section C already gives for "no description", so all three agree. title needs no equivalent rule and must not be given one by symmetry: both DTOs declare it a required string. AC-71 governs. Recording is otherwise unconditional: it is never suppressed by an open editor or an in-flight write. Only the application of a canonical value to the displayed value is guarded (AC-49). The third trigger is not bookkeeping. Without it the client's own successful edit is never recorded, so the deferred apply defined below would land the pre-write value the instant the guard released and visibly revert a save that had just succeeded.
• Stale responses are discarded, not recorded. Each fetch records, per field, the client's write generation for that field at the moment the request is issued. A response is stale for a field if this client committed a write to that field after the request was issued, and a stale response is discarded for that field only: it is neither recorded as canonical nor applied. Other fields of the same response are unaffected. This is what stops a refetch begun before a save from resolving afterwards and reinstating the pre-save text (AC-52). Staleness is judged by request-issue order, not by comparing values, so a response that happens to carry a third party's newer value but was requested before this client's write is discarded too. That is deliberate and costs nothing durable: the third party's write published its own task.updated, so a fresh refetch is already on its way.
• Recordings are ordered by tasks.updated_at, and a strictly older recording is discarded. A candidate recording is accepted only if the updated_at its payload carries for the task is not older than the updated_at carried by the field's currently recorded canonical value. A strictly older candidate is discarded for that field: neither recorded nor applied (AC-60). updated_at is the right column precisely because section F already establishes that it is stamped inside the write transaction, so its order matches true serialization order.
  • This applies to all three record triggers, a write's own response (AC-58) included, not only to refetches. That is load-bearing rather than tidiness: when two title commits overlap and the server commits them in the opposite order to the one the client issued them in, the two write responses carry the row's two successive updated_at values, so ordering by that column records whichever write the row actually kept. Recording by arrival order instead would leave the canonical value at the losing write. This is a second, independent reason AC-54 converges.
  • Tiebreak, named. When two instants are exactly equal, the later-arriving recording wins, ordered by this client's request-issue sequence for the task (AC-63). That sequence is a single per-task counter, incremented on every request this client issues for the task, fetch or write, so every candidate recording carries one. Equal updated_at means the same row version, so the field values agree and the choice is not observable; the tiebreak exists so the rule is total instead of leaving Build to invent one, and it does real work only where a second-resolution timestamp format is in play.
  • Compare parsed instants, never raw strings, and note that the two formats are further apart than they look. The three record triggers do not agree on serialization, and the disagreement is not a fractional-second detail. It is two different date syntaxes.
    • The Office task DTO feeds two of the three triggers, the initial load (AC-59) and every refetch (AC-49). It passes the SQLite updated_at column straight through as a raw string (internal/office/repository/sqlite/tasks.go, TaskSearchResult.UpdatedAt string). What is in that column is written by updateTaskTx, which binds task.UpdatedAt as a Go time.Time to mattn/go-sqlite3; that driver's default bind layout is 2006-01-02 15:04:05.999999999-07:00: space-separated, with a numeric offset (+00:00), never a T, never a Z, and not ISO-8601. This is established in this repository, not inferred: internal/analytics/repository/sqlite/stats.go carries a comment recording the bug it already caused ("RFC3339 put a 'T' where every stored value has a space, and 'T' sorts above ' ', so rows silently lost their first day"); the same layout is referenced in internal/office/repository/sqlite/failure.go and internal/task/repository/sqlite/worktree_ownership_normalize.go; and internal/office/dashboard/service_inbox.go's parsedTaskUpdatedAt needs four fallback layouts and still falls back to time.Now() when all four miss.
    • A write's own response (AC-58) carries TaskDTO.UpdatedAt time.Time (internal/task/dto/dto.go), marshalled by encoding/json, which is RFC3339Nano: the T/Z form. The task.updated WS payload uses the same form (internal/task/service/service_events.go), though that payload is not a record trigger; it is named here only so a builder does not add it as a fourth one. So a comparison between a refetch recording and a write recording is a comparison between 2026-08-20 14:30:05.123456789+00:00 and 2026-08-20T14:30:05.123456789Z. As text they do not order at all; the space sorts below T, so the raw-string comparison is not merely imprecise, it is systematically wrong in one direction. The trailing-zero hazard is real too, and survives within the RFC3339Nano form alone, because RFC3339Nano strips trailing zeros from the fractional second, so ...:05.1Z and ...:05.05Z do not order correctly as text either. The requirement: parse every candidate's updated_at to an absolute instant before comparing, accepting both layouts above. The space-separated form must be parsed explicitly, treating its trailing offset as authoritative; it must not be handed to Date.parse / new Date(...) and assumed, because that string is not an ISO-8601 date-time and browsers do not agree on how or whether to parse it, with some treating it as local time. AC-66 governs.
  • A candidate whose updated_at cannot be parsed is discarded, and is never treated as newest. If parsing fails, that candidate is dropped for that field: neither recorded as canonical nor applied to the displayed value. It must not fall back to the current time, and must not be accepted on the grounds that it arrived most recently. The backend precedent in parsedTaskUpdatedAt does fall back to time.Now(), and copying it here would be actively wrong rather than merely lax: this rule discards anything strictly older than the recorded value, so a "now" fallback always compares as newest, always wins, and silently defeats the entire ordering rule for exactly the malformed inputs it exists to protect against. Dropping the candidate is safe because no canonical value is lost: the field keeps the value it already had, and the next load, refetch or successful write records again. AC-67 governs.
  • The first recording for a field is a seed and is never discarded. The two rules above are comparisons, and until a field has a recorded canonical value there is nothing to compare against, so the first recording is made unconditionally: neither the staleness rule, nor the updated_at ordering rule, nor the parse rule can reject it (AC-72). This matters because section F's rollback target is the recorded canonical value (AC-64), so a field that reached an editable state with no canonical value at all would leave a failed commit with nothing to restore. AC-59 makes the initial page load the seed, and it necessarily precedes any edit, so in practice the seed is always in place before a commit can be issued.
  • An unknown instant loses to a known one. If the seed's updated_at could not be parsed, the field has a canonical value but no comparable instant. Any later candidate whose updated_at does parse supersedes it (AC-73), rather than being discarded for failing a comparison against something uncomparable. Without this the field would be pinned to the seed for the lifetime of the page. This rule closes two races the write-generation rule above does not reach: two refetches resolving out of order (AC-60), and a refetch issued after a commit that nonetheless read a pre-write snapshot and resolves after the write's own response (AC-62). Which rule applies to which trigger, stated rather than left to be inferred. A refetch response must survive both the staleness rule and this ordering rule to be recorded. A write's own response is subject to this ordering rule only; the staleness rule above is written against a refetch response and must not be extended to write responses. Extending it would be actively wrong rather than merely redundant: when two title commits overlap, the second is by definition committed after the first was issued, so a staleness test would discard the first commit's own response, and if the server happened to commit that first write last, the client would record the losing value and disagree with the row permanently.
• The in-flight guard (applies to the displayed value only). A canonical value is applied to a field's displayed value only when that field has no unresolved write of this client's own and no open editor for it. The guard is per field and covers three windows that would otherwise each lose a user's work:
  1. an open editor (AC-28): the draft is never touched;
  2. an in-flight optimistic title, where the editor has already closed at commit time (AC-3), so an editor-open test alone does not protect it (AC-38);
  3. a refetch triggered by an unrelated concurrent mutation on the same task, for example another property picker firing while a title PATCH is still in flight; that refetch can read a snapshot taken before this client's write and would otherwise revert it (AC-39). A field with no unresolved write and no open editor is unguarded, and a canonical value lands on it immediately, so an ordinary remote edit still appears promptly.
• Deferred apply on release. A field is unguarded when both conditions hold at once: it has no open editor and no unresolved write of this client's own. At the moment a field becomes unguarded, whether because its editor closed by any route (Save, Cancel, Escape, discard-confirm) or because its last in-flight write resolved, the client applies the field's most recently recorded canonical value to the displayed value if the two differ. If several canonical values were recorded while the field was guarded, only the most recent one is applied; the earlier ones are superseded, not queued. On the successful-save path this runs after the editor closes and AC-17 renders the saved value, and it can only ever move the display forward onto something newer, never back onto the pre-save text. Three rules together are what make that true, and all three are load-bearing: the save's own success has already recorded the persisted value as this field's canonical value (AC-58), so the canonical value is not stale to begin with; a response whose request predates the save is discarded as stale (AC-52); and any surviving response carrying an older updated_at is discarded by the ordering rule (AC-60). Earlier drafts of this document rested the same claim on AC-52 alone, which was wrong: a canonical value recorded legitimately before the save was issued is not stale under AC-52 and would have been applied over the saved text. This is the half of the convention the guard would otherwise drop. Without it, a canonical value that arrived while the field was guarded would be recorded and never shown: a remote edit landing during an open editor that the user then cancels would leave stale text on the page forever, because no further event is coming. AC-50 governs, and it is what keeps AC-27 true in the guarded case. apps/web/AGENTS.md names this exact shape as the established convention for this class of race: "guard responses with per-scope revision and request/workspace generation; discard or refresh stale responses and cover deferred responses".
• Guard lifetime: the guard is DERIVED, never independently set. A field is guarded exactly when at least one of two underlying facts holds: an editor is open for it, or a write of this client's own to it is unresolved. The guard is computed from those two facts; it is not a third piece of state that one code path sets and another must clear. That shape is mandatory rather than stylistic, because a separately-mutated flag is precisely what can be left set by a path that never runs its clear, and a permanently-set guard is invisible: it produces no error, it silently freezes the field's Office task store entry for that task, and AC-61 makes the WebSocket handler honour it, so the task's cards on the list and board stop updating for the rest of the session with nothing to indicate why. The lifetime rules follow from the derivation and are stated so Build does not have to derive them:
  • Creation. No explicit creation step exists. A (task, field) pair is guarded from the moment one of the two facts becomes true. The guard is keyed by task and field, not by component, and there is at most one open-editor contribution per field because the Office simple pane is the only surface this feature gives an editor to. A second view of the same task does not add a second contribution.
  • Editor closing, including unmount and route change. When the detail page unmounts, or the route changes away from it, its open-editor contribution for both fields ends unconditionally, exactly as if the editor had been closed (AC-68). An unmount is not a special case that skips cleanup; it is the ordinary close path.
  • A write resolving. A write's contribution ends when it resolves, whether it succeeded or failed (AC-70). A failed write is a resolved write. This is called out because the failure path is the one a builder is most likely to leave without a release, and because it also records no canonical value, so nothing later would correct a guard left set by it.
  • A write that resolves after the page is gone. It still records its canonical value (AC-58 is unconditional and does not depend on a mounted page) and it still ends its own contribution. The deferred apply then has no displayed value to write to, so it applies to the Office task store entry only (AC-69). The task's card therefore ends on the persisted value even though the user navigated away mid-write.
  • Garbage collection. No guard entry may outlive both of its underlying facts. Once a field has no open editor and no unresolved write it is unguarded and holds no state, and an implementation that keeps a per-task map must not leave a set entry behind for a task the user has left (AC-69).
• Why the guard is needed at all here. refetchTask in apps/web/app/office/tasks/[id]/page.tsx calls setTask(mapOfficeTaskToTask(res.task)), replacing the whole task object rather than merging fields, and patchTaskInStore writes the store entry the same way. Applying a response wholesale is therefore the default behaviour that has to be constrained.
• The Office task store follows the same rule, with per-field timing. A title edited on the detail page must update the task's card in list and board views. The title store patch is applied at commit-issue time, in lockstep with the optimistic render (AC-3), which is what makes AC-39's protection meaningful: the store already carries the unconfirmed value while the request is in flight. The description store patch is applied only on success, because section C makes description Save non-optimistic and an optimistic card preview would contradict it (AC-11, AC-56). Both require title and description to be carried by the store patch mapping in apps/web/hooks/use-optimistic-task-mutation.ts, which currently drops both.
• There are TWO writers of these fields into the Office task store, and both consult the guard. The guard is a property of the task and the field, not of the detail-page component. Naming only the first writer is what previously made AC-39 and AC-56 unsatisfiable:
  1. patchTaskInStore, reached from the optimistic-mutation hook and from the page's refetch path.
  2. apps/web/lib/ws/handlers/office.ts. Its office.task.updated handler calls updateTaskStatus(taskId, normalizeIssueFields(p)). normalizeIssueFields maps p.title and p.description off the event payload, and updateTaskStatus merges them into state.office.tasks.items with a raw store.setState, synchronously on every event, bypassing patchTaskInStore and everything this section constrains. For title and description both writers are subject to the per-field guard (AC-61). The practical consequence, which Build must plan for rather than discover: the guard state has to be reachable from a module-level store subscriber, so component-local state alone cannot satisfy AC-61. Where that state lives is Build's choice; that both writers read the same guard is not.
• Why the WS handler is routed through the guard rather than stripped. Two alternatives were considered and rejected, and this is recorded because the choice was left open rather than directed. Stripping title and description from normalizeIssueFields, so the guarded refetch path became the sole store writer, is the smaller diff and would also satisfy AC-39 and AC-56. It was rejected because that handler is shared by the Office list and board, where no editor is ever open and no write is ever in flight: stripping the two fields would make every remote title change on those surfaces wait for a refetch instead of landing synchronously, which is a regression for users on surfaces this feature otherwise does not touch. Accepting the handler as an unguarded writer, and weakening AC-39 and AC-56 to match, was rejected because AC-39 exists precisely for the routine case of an unrelated picker firing mid-write. Routing keeps the synchronous fast path for the common unguarded case, keeps both ACs intact, and puts the rule in one place, so a third writer added later inherits it instead of silently defeating it the way this one did.
• The store's unguarded path is deliberately not ordered, and that is stated rather than left silent. While a field is unguarded the WS handler writes the payload value into the store directly, and a refetch response may write a different value moments later. Both carry server state, WS delivery on a single connection is ordered, and any disagreement is corrected by the next event or refetch, so the window is bounded and self-correcting. No ordering guarantee is claimed for the store entry while the field is unguarded and no test should assert one. The updated_at ordering rule governs canonical recording, which is what the displayed value is derived from; it is not extended to the store's unguarded fast path.
• Store rollback is field-scoped. A failed title commit rolls back the store entry's title under the same sequence rule and to the same target as the displayed title (section F, "Rollback ordering": the currently recorded canonical value, AC-64), and rolls back nothing else. Without this the task's card keeps showing a rejected, unpersisted title permanently, because a failed write is never persisted and no task.updated is ever published to correct it. Note that useOptimisticTaskMutation today restores the whole storeSnapshot on failure, which would revert unrelated fields another writer changed in the meantime; it must not be reused unchanged for this. AC-55 governs.
• A manual title edit clears any pending agent-generated title for the task: Service.UpdateTask deletes the agent_title_pending and agent_title_owner_session_id metadata keys whenever a title is supplied, and the row is then written unconditionally. A human title always wins over an agent title that has not landed yet. A description-only edit leaves the pending marker intact, and the backend's conditional title write then applies; see section F.

F. Ordering, concurrency, and retries

• Ordering. The two fields are independent single-column writes to one row; this feature introduces no list, no sort, and no tiebreak. When several edits are committed in sequence, the effective order is commit order, and the persisted tasks.updated_at is stamped inside the write transaction (repository/sqlite/task.go, updateTaskTx), so its ordering matches true serialization order.
• Concurrency, general case. Service.UpdateTask is a read-modify-write: it loads the row, applies the patch, and issues a full-row UPDATE. For every column except title and the title-related metadata keys there is no version or updated_at precondition, so two writers resolve last-commit-wins, and a write can carry a stale value for a field it did not intend to change if a different writer committed inside the window between its read and its write. This is pre-existing behaviour of the shared endpoint, it applies equally to every current caller, and this feature does not change it. Adding general optimistic concurrency control is named out of scope below.
• Concurrency, the title exception (do not assume last-commit-wins here). updateTaskTx is not a single statement. When the caller's in-memory snapshot still carries agent_title_pending, it issues a conditional update whose title assignment is title = CASE WHEN <live pending marker> THEN ? ELSE title END, together with a JSON merge of the title metadata. That is a genuine compare-and-swap against live database state, it exists so an agent-generated title cannot overwrite a human one that landed first, and it is covered by dedicated tests in apps/backend/internal/task/repository/sqlite/task_title_cas_test.go (TestSetTaskTitleIfPendingRequiresTrueMarker, TestSetTaskTitleIfPendingRejectsNonOwner, TestUpdateTaskPreservesWinningTitleAgainstStaleUpdate, TestClaimTaskTitleSessionIsSingleOwner). Service.UpdateTask acknowledges this in a comment: the post-write snapshot may be stale precisely because a conditional title patch was applied. This feature exercises that path directly: a description-only save on a task whose agent title is still pending goes through the conditional statement, and AC-48 requires it to be tested rather than assumed. Do not "simplify" this branch and do not treat that window as an unguarded race already excluded from scope.
• Rollback ordering (overlapping title commits). Title commits are sequenced. Each commit takes a monotonically increasing sequence number when it is issued. A failed commit restores the title only if it is the last word standing: only if there exists no later-sequenced commit that has already resolved successfully and no later-sequenced commit that is still unresolved. Otherwise the restore is skipped and the displayed title is left alone. The error is surfaced as a toast either way, and the same condition governs the store rollback (section E).
• What a rollback restores: the field's currently recorded canonical value, read at the moment the restore runs. It is not a per-commit snapshot of whatever happened to be displayed when that commit was issued. This definition is corrected from an earlier draft and the reasoning is recorded here so it is not rediscovered the hard way. A value captured at issue time can be the optimistic value of an earlier commit that later failed, a title the server never persisted; restoring it puts the page into precisely the state AC-44's rationale says must never occur. A canonical value cannot carry that defect by construction: section E records one only from the initial load, a surviving refetch, or a successful write, so every canonical value is one the server confirmed it holds. AC-64 governs. Two consequences, both load-bearing:
  • Restoring is idempotent. Two failed commits that both restore land on the same value, so the order in which they resolve cannot change the end state.
  • The restore and section E's deferred apply agree by construction, not by sequencing. Both write the same canonical value, so when a guard release and a rollback coincide it does not matter which runs first. No ordering between them is specified, and none is needed. The exclusions are load-bearing and none is redundant. The partition is over the state of later-sequenced commits, and all four of its cases are named:
  • A later commit that already succeeded (AC-44). Restoring here would silently revert a newer successful commit, leaving a title that is neither what the user typed nor what is stored.
  • A later commit still in flight (AC-53). The displayed title currently shows that newer commit's optimistic value. Restoring the older snapshot would overwrite it, and a commit succeeding re-renders nothing on its own (AC-3 renders at issue time only), so the newer commit's success would not correct the display. It would be corrected only later and only indirectly, when a canonical value arrives and the deferred apply runs, which is at least an event round-trip away and shows the user a title they did not type in the meantime. The narrower rule that named only the already-resolved case therefore mandated a mismatch it was written to prevent.
  • A later commit that has already resolved with FAILURE is not an exclusion, and does not block this commit's restore (AC-65). This is the fourth case and it is named explicitly rather than left to be inferred from "neither succeeded nor still unresolved", because leaving it implicit is what previously let a chained double failure land on a never-persisted title: under the old snapshot-based restore target, the later commit's snapshot was the earlier commit's optimistic value, so whichever of the two resolved last restored a title that had never been stored, and the end state depended on network ordering alone. It is safe now because of the corrected restore target above: both commits restore to the same canonical value, so the second restore is a no-op rather than a revert, and the end state is the same whichever order they resolve in.
  • No later-sequenced commit at all is the ordinary single-commit case and restores (AC-9).
• Convergence after overlapping commits (both succeed). Sequence numbers order the client's rollbacks; they do not reorder the network. If commit 1 sends B and commit 2 sends C and the requests reach the server out of order, the row keeps whichever write committed last, which may be B, while the display shows C. This feature does not add ordering guarantees to the wire and does not re-send to force a winner. It converges instead, and by a shorter path than an event round-trip: each write's own response records the row's value for that field as canonical, ordered by updated_at (section E), so by the time the later-resolving commit's response has landed, the canonical value is already whichever write the row actually kept. Once the last commit resolves the title is unguarded and the deferred-apply rule lands that value on the display. The refetches driven by each task.updated are a second, redundant path to the same end state rather than the mechanism convergence depends on. The end state is therefore the row's value, reached without a page reload, and the window in which the display disagrees with the row is bounded by the in-flight commits alone. AC-54 observes this. Users who care about which of two rapid renames wins are asking for general optimistic concurrency control, which is named out of scope below.
• Late-arriving refresh. A WS-driven refetch that lands while an editor is open must not overwrite the user's draft, and must not overwrite an in-flight optimistic value either; the per-field guard in section E states the full rule. The field's canonical value behind an open editor may change, and is recorded when it does; what the guard suppresses is only its application to the displayed value, and that application is deferred to the moment the editor closes rather than dropped (section E, "Deferred apply on release"). Meanwhile the editor's baseline is frozen at open time (section C for the description, section B for the title), so Save, Cancel, and Escape behaviour never changes underneath the user as a result of somebody else's edit. Those two statements are consistent because they are about different values: the canonical value moves, the displayed value and the baseline do not.
• Idempotency. A commit whose trimmed value equals the baseline or the current title issues no request. Committing the same value twice is therefore a single write followed by a no-op, and re-sending an identical PATCH converges on the same value: title and description are assigned, not accumulated, so N identical requests leave the same row as one. It is idempotent in that sense only. Each request is still a real write that re-stamps updated_at inside the transaction and republishes task.updated, so duplicates are observable as extra events and extra refetches even though the field value never moves. This feature adds no idempotency key and no duplicate-request suppression, and needs neither: it issues no automatic retries, and a commit equal to the baseline issues no request at all, so this client never sends a duplicate of its own.
• Retries. No automatic retry on failure. A failed title commit rolls back subject to the rollback-ordering rule above and toasts; a failed description save keeps the editor open with the draft and toasts. In both cases the next attempt is a fresh user action.

G. Errors

• Network failure, 5xx, or a task that no longer exists (404) means the edit does not apply, the prior value is restored (title) or the editor stays open with the draft (description), and the message surfaces as a toast.
• 400 from title validation is unreachable through the UI, because the input clamps at the same 60-character limit the server enforces. If it is returned anyway, it is surfaced as a toast like any other failure; no special-cased inline error is required.
• The failure path never leaves an invisible unsaved draft. Either the editor is open and the draft is visible, or the editor is closed and the visible text is the stored text.

H. Interaction details a builder would otherwise have to invent

• Keyboard parity. Both affordances are reachable and operable without a pointer. The title element and the description element (or its empty-state placeholder) are focusable, and Enter on the focused element opens the corresponding editor. Pointer activation is double-click for the title and single click for the description; the asymmetry is deliberate: a single click on a paragraph of prose is how every comparable product opens a description, while a single click on a page heading is not, and the title's double-click matches the existing Kanban rename.
• Click versus text selection. A pointer interaction on the description that ends with a non-empty text selection does not open the editor. Selecting and copying description text must remain possible.
• The two editors are independent in state, but not symmetric about focus. Neither editor ever commits the other, and a dirty description draft never blocks a title commit (AC-35). They are not, however, both freely open at once, and the asymmetry follows from blur:
  • The description editor survives blur (AC-21), so it stays open with its draft while the user opens, edits, and commits the title editor. That order is safe and AC-35 covers it.
  • The title editor cancels on blur (AC-5). Opening the description editor necessarily moves focus off the title input, whether by pointer or by keyboard, so the title editor closes and its draft is discarded. AC-57 states this explicitly rather than leaving it to be discovered. This is deliberate, not an oversight: the title editor is transient by design, matching the existing Kanban rename, and section C's rationale explains why a lost title draft is cheap (one line, at most 60 characters) while a lost description draft is not. A user who wants to keep a title draft commits it with Enter first. If a future card wants both editors genuinely co-open, that is a change to AC-5, not to this bullet.
• Overlapping title commits. A second title commit issued while the first is still in flight is allowed. Sequencing and the rollback rule are specified in section F under "Rollback ordering"; that rule, not a per-commit snapshot alone, is what guarantees a failure never reverts a newer successful commit.
• Cancel confirmation shape. The AC-19 confirmation is a modal with two choices: discard the draft and close the editor, or return to the editor with the draft intact. Dismissing the modal by any other means (Escape, backdrop, close button) returns to the editor with the draft intact. The draft is only ever destroyed by the explicit discard choice.
• Save and Cancel placement. Save and Cancel render below the textarea, Save first and styled as the primary action, Cancel secondary. This is a fresh product decision for this feature, not a port: project-header.tsx has a single Save button rendered above its textarea and no Cancel control at all, so it is a precedent for gating Save on dirty state and for nothing else.
• Invalid-title feedback. AC-7's invalid state is both programmatic and visible: aria-invalid on the input plus a short visible message adjacent to it. It clears as soon as the draft becomes non-empty.
• Stable test hooks. The implementation exposes these data-testid values, and the E2E spec addresses the feature through them rather than through copy: office-task-title, office-task-title-input, office-task-title-error, office-task-description, office-task-description-empty, office-task-description-textarea, office-task-description-save, office-task-description-cancel, office-task-description-discard-confirm, office-task-description-running-note.

Acceptance criteria

Written in EARS form. Each is observable from the Office task detail page or from the persisted row.

Title

• AC-1: WHEN the user double-clicks the task title on the Office simple pane, THE SYSTEM SHALL replace it with a focused single-line input seeded with the current title and its content selected.
• AC-2: WHEN the title element has keyboard focus AND the user presses Enter, THE SYSTEM SHALL enter the same edit state as AC-1.
• AC-3: WHILE the title editor is open AND the trimmed draft is non-empty AND differs from the stored title, WHEN the user presses Enter, THE SYSTEM SHALL render the trimmed draft immediately, send PATCH /api/v1/tasks/:id with a body containing only title set to that same trimmed value, and close the editor.
• AC-4: WHILE the title editor is open, WHEN the user presses Escape, THE SYSTEM SHALL discard the draft, close the editor, restore the stored title, and send no request.
• AC-5: WHILE the title editor is open, WHEN the input loses focus, THE SYSTEM SHALL behave exactly as in AC-4.
• AC-6: WHILE the title editor is open, WHEN the user enters or pastes text that would take the field beyond 60 code points, THE SYSTEM SHALL retain only the first 60 and SHALL leave the caret at the position the user was typing or pasting at, not at the end of the field.
• AC-7: WHILE the title editor is open AND the trimmed draft is empty, WHEN the user presses Enter, THE SYSTEM SHALL keep the editor open, mark the field invalid to assistive technology, and send no request.
• AC-8: WHILE the title editor is open AND the trimmed draft equals the stored title, WHEN the user presses Enter, THE SYSTEM SHALL close the editor and send no request.
• AC-9: IF the title PATCH fails AND no later-sequenced title commit has already resolved successfully AND no later-sequenced title commit is still unresolved, THEN THE SYSTEM SHALL restore the title's currently recorded canonical value (AC-64) and surface the error as a toast. (Both exclusions are required: this is the "last word standing" condition from section F, and AC-44 and AC-53 are the two cases it excludes. An earlier version of this criterion carried only the first exclusion, which made it mandate a restore in exactly the situation AC-53 forbids. A second earlier version restored a per-commit snapshot of the displayed title, which could be a never-persisted value; AC-64 replaced that target and AC-65 observes the case that exposed it.)
• AC-10: WHILE an IME composition is active, WHEN the user presses Enter, THE SYSTEM SHALL NOT commit the title and SHALL leave the editor open.
• AC-11: WHEN a title commit is issued, THE SYSTEM SHALL patch the task's entry in the Office task store with the trimmed draft at that moment, before the request resolves, so list and board surfaces show the new title without waiting for a WebSocket message. (Issue time, not success time: AC-39's protection of that store entry during the in-flight window is only meaningful if the entry already carries the unconfirmed value.)
• AC-44: IF a title PATCH fails AND a later-sequenced title commit has already resolved successfully, THEN THE SYSTEM SHALL leave the displayed title unchanged, SHALL NOT perform a restore, and SHALL still surface the error as a toast.
• AC-51: WHILE the title editor is open, THE SYSTEM SHALL use the title displayed at editor-open time as the frozen baseline for AC-4's restore target and AC-8's equality test, AND SHALL NOT change that baseline when a newer canonical title is recorded for the task.
• AC-53: IF a title PATCH fails AND a later-sequenced title commit is still unresolved, THEN THE SYSTEM SHALL leave the displayed title and the Office task store entry unchanged, SHALL NOT perform a restore, and SHALL still surface the error as a toast.
• AC-54: WHEN two overlapping title commits both succeed, THE SYSTEM SHALL converge the displayed title on the task's stored value once no title write is in flight and no title editor is open, without a page reload, regardless of the order in which the two requests reached the server.
• AC-55: IF a title commit fails AND the rollback condition in section F is met, THEN THE SYSTEM SHALL set the Office task store entry's title to the title's currently recorded canonical value and SHALL leave every other field of that store entry at its current value.
• AC-64: WHEN a failed title commit performs a restore, THE SYSTEM SHALL restore the title's currently recorded canonical value read at the moment the restore runs, and SHALL NOT restore any value captured from the display at commit-issue time.
• AC-65: WHEN two overlapping title commits both fail, THE SYSTEM SHALL leave the displayed title and the Office task store entry at the title's currently recorded canonical value, and SHALL reach the same end state regardless of which of the two commits resolves first.

Description

• AC-12: WHEN the user clicks the task description, THE SYSTEM SHALL replace it with a focused textarea seeded with the current description.
• AC-13: WHERE the task has no description, THE SYSTEM SHALL render a persistent placeholder affordance in the description's position, and WHEN the user clicks it, THE SYSTEM SHALL enter the same edit state as AC-12 with an empty draft.
• AC-14: WHILE the description editor is open AND the trimmed draft differs from the frozen baseline, THE SYSTEM SHALL display an enabled Save control and a Cancel control.
• AC-15: WHILE the description editor is open AND the trimmed draft equals the frozen baseline, THE SYSTEM SHALL display Save in a disabled state.
• AC-16: WHEN the user activates Save, THE SYSTEM SHALL send PATCH /api/v1/tasks/:id with a body containing only description set to the trimmed draft, SHALL keep the editor open in a saving state until the request resolves, and SHALL disable Save for the duration.
• AC-17: WHEN a description save succeeds AND the current trimmed draft still equals the submitted value, THE SYSTEM SHALL close the editor and render the saved value.
• AC-18: IF a description save fails, THEN THE SYSTEM SHALL keep the editor open with the draft unchanged and surface the error as a toast.
• AC-19: WHILE the description editor is open AND the trimmed draft differs from the frozen baseline, WHEN the user activates Cancel, THE SYSTEM SHALL require an explicit confirmation before discarding the draft.
• AC-20: WHILE the description editor is open AND the trimmed draft equals the frozen baseline, WHEN the user activates Cancel, THE SYSTEM SHALL close the editor immediately without a confirmation.
• AC-21: WHILE the description editor is open, WHEN the textarea loses focus, THE SYSTEM SHALL keep the editor open, keep the draft, and send no request.
• AC-22: WHILE the description editor is open AND the trimmed draft differs from the frozen baseline, WHEN the user presses Escape, THE SYSTEM SHALL take no action.
• AC-23: WHILE the description editor is open AND the trimmed draft equals the frozen baseline, WHEN the user presses Escape, THE SYSTEM SHALL close the editor.
• AC-24: WHEN a description save commits an empty trimmed draft on a task that previously had a description, THE SYSTEM SHALL clear the stored description and SHALL then render the placeholder affordance from AC-13.
• AC-25: WHILE at least one session on the task is in state RUNNING, WHEN the description editor is open, THE SYSTEM SHALL display a non-blocking note stating the change applies at the agent's next wakeup, and SHALL NOT disable Save.
• AC-40: WHILE the description editor is open, WHEN an office.task.updated refetch changes the task's stored description, THE SYSTEM SHALL leave the editor's frozen baseline unchanged, so that the enabled state of Save and the behaviour of Cancel and Escape do not change as a result.
• AC-41: WHILE a description save is in flight, THE SYSTEM SHALL keep the textarea editable, SHALL disable both Save and Cancel, and SHALL take no action on Escape.
• AC-42: WHEN a description save succeeds AND the user changed the draft while the save was in flight, THE SYSTEM SHALL keep the editor open with the newer draft intact, SHALL set the baseline to the value that was saved, and SHALL re-enable Save while the newer trimmed draft differs from it.
• AC-43: WHERE the stored description is empty, WHILE the description editor is open AND the draft contains only whitespace, THE SYSTEM SHALL treat the draft as equal to the baseline, SHALL keep Save disabled, and SHALL send no request.
• AC-45: WHEN the user saves a description of any length, THE SYSTEM SHALL send and persist it unmodified apart from whitespace trimming, applying no client-side or server-side length limit.
• AC-46: WHEN a description containing Markdown syntax is rendered, THE SYSTEM SHALL display it as literal plain text with whitespace preserved, and SHALL NOT render it as formatted Markdown.
• AC-56: WHEN a description save is issued, THE SYSTEM SHALL NOT patch the Office task store entry, and WHEN that save succeeds, THE SYSTEM SHALL patch the store entry's description at that moment, so card previews never show a description that has not been persisted.

Shared

• AC-26: WHEN either field is committed AND no other writer commits to the same task inside the request window, THE SYSTEM SHALL send only the edited field in the request body and SHALL leave every other task property unchanged in the response. This feature asserts no outcome when a concurrent writer does commit inside that window: Service.UpdateTask is last-commit-wins for every column except the existing title compare-and-swap (section F), this feature neither adds nor removes that behaviour, and no test should assert a required winner. Section F describes what the backend does today; it does not impose a new requirement here.
• AC-27: WHEN another client edits the same task, THE SYSTEM SHALL update the displayed title and description without a page reload: immediately on receipt of office.task.updated WHERE the field is unguarded, and otherwise at the moment that field becomes unguarded, per the deferred apply in AC-50. This criterion promises convergence without a reload; it does not promise application during a guarded window. AC-28 and AC-38 govern the guarded window and take precedence there. (An earlier version said only "on receipt", which contradicted the guard and would have failed a correct implementation.)
• AC-28: WHILE either editor is open, WHEN an office.task.updated refetch resolves for this task, THE SYSTEM SHALL leave the open draft unmodified.
• AC-38: WHILE a title commit is in flight AND the title editor has already closed, WHEN an office.task.updated refetch for this task resolves, THE SYSTEM SHALL leave the optimistically rendered title unchanged.
• AC-39: WHILE a title commit is in flight, WHEN a refetch triggered by an unrelated mutation on the same task resolves and carries a title predating that commit, THE SYSTEM SHALL leave both the displayed title and the Office task store entry unchanged.
• AC-49: WHEN a non-stale refetch for this task resolves, THE SYSTEM SHALL record its value for each field as that field's canonical value, whether or not an editor is open for that field and whether or not a write to that field is in flight.
• AC-50: WHEN a field becomes unguarded, because its editor closed by any route or because its last in-flight write resolved, THE SYSTEM SHALL apply that field's currently recorded canonical value to the displayed value if the two differ, so that a remote edit received while the field was guarded becomes visible without a page reload.
• AC-52: IF a refetch response's request was issued before this client's most recent committed write to a field, THEN THE SYSTEM SHALL discard that response for that field, neither recording it as canonical nor applying it to the displayed value.
• AC-58: WHEN a write to a field resolves successfully, THE SYSTEM SHALL record the value that request persisted for that field, read from the response body, as that field's canonical value, AND SHALL do so before releasing that field's guard.
• AC-59: WHEN the task detail page completes its initial load, THE SYSTEM SHALL record the loaded title and description as those fields' canonical values.
• AC-60: IF a candidate canonical recording carries an updated_at strictly older than the updated_at carried by the field's currently recorded canonical value, THEN THE SYSTEM SHALL discard the candidate for that field, neither recording nor applying it, so that two refetches resolving out of order leave the newer value in place.
• AC-61: WHILE a field is guarded, WHEN an office.task.updated event is received, THE SYSTEM SHALL leave that field's Office task store entry unchanged, INCLUDING when the store write originates in the WebSocket handler rather than in the page's refetch path.
• AC-62: IF a refetch was issued after a commit to a field AND its response carries an updated_at older than the one recorded by that commit's own successful response, THEN THE SYSTEM SHALL discard that response for that field.
• AC-63: WHEN two candidate recordings for a field carry exactly equal updated_at values, THE SYSTEM SHALL accept the later-arriving one, ordered by this client's request-issue sequence for the task.
• AC-66: WHEN comparing two candidate recordings' updated_at values, THE SYSTEM SHALL parse each to an absolute instant before comparing, SHALL accept both the space-separated offset-bearing layout emitted by the Office task DTO and the RFC3339Nano layout emitted by a write response, and SHALL NOT compare the values as raw strings.
• AC-67: IF a candidate recording's updated_at cannot be parsed to an absolute instant, THEN THE SYSTEM SHALL discard that candidate for that field, neither recording it as canonical nor applying it to the displayed value, and SHALL NOT treat it as newer than the recorded value.
• AC-68: WHEN the task detail page unmounts or the route changes away from it, THE SYSTEM SHALL end the open-editor contribution to the guard for both fields, so that a field with no unresolved write becomes unguarded.
• AC-69: WHEN a write resolves after the task detail page has unmounted, THE SYSTEM SHALL record its canonical value per AC-58, SHALL end that write's contribution to the guard, and SHALL leave no guard entry in place for a field that has no open editor and no unresolved write.
• AC-70: WHEN a write to a field fails, THE SYSTEM SHALL end that write's contribution to the field's guard exactly as it does for a write that succeeds.
• AC-71: WHEN a canonical value is recorded for description, THE SYSTEM SHALL normalise an absent value (undefined, null, or an omitted field) to the empty string before recording it, so that a guard release on a task with no description applies nothing.
• AC-72: WHEN a field has no recorded canonical value, THE SYSTEM SHALL record the next candidate for that field unconditionally, applying neither the staleness rule, nor the updated_at ordering rule, nor the parse rule to it.
• AC-73: IF a field's recorded canonical value carries an updated_at that could not be parsed, THEN THE SYSTEM SHALL accept the next candidate whose updated_at does parse, superseding the recorded value.
• AC-29: WHEN a title is committed on a task carrying a pending agent-generated title, THE SYSTEM SHALL persist the user's title and SHALL clear the task's pending-agent-title metadata.
• AC-48: WHEN a description-only save is committed on a task carrying a pending agent-generated title, THE SYSTEM SHALL persist the new description, SHALL leave the pending-agent-title metadata intact, and SHALL leave the stored title unchanged.
• AC-30: THE SYSTEM SHALL offer the title and description editors regardless of the task's status and regardless of any session state, introducing no status-based or lifecycle-based gate.
• AC-47: THE SYSTEM SHALL NOT introduce an archived-task gate on either editor, and SHALL NOT port the isArchived condition from apps/web/components/task/task-top-bar-title.tsx.
• AC-31: THE SYSTEM SHALL NOT queue an agent run, wake an agent, or interrupt a running session as a result of a title or description edit.

Interaction details

• AC-33: WHEN the title element or the description element has keyboard focus AND the user presses Enter, THE SYSTEM SHALL open the corresponding editor.
• AC-34: WHEN a pointer interaction on the description ends with a non-empty text selection, THE SYSTEM SHALL NOT open the description editor.
• AC-35: WHILE the description editor is open with a dirty draft, WHEN the user opens and commits the title editor, THE SYSTEM SHALL commit the title and SHALL leave the description editor open with its draft intact.
• AC-36: WHILE the AC-19 confirmation is displayed, WHEN the user dismisses it by any means other than the explicit discard choice, THE SYSTEM SHALL return to the description editor with the draft intact.
• AC-37: WHILE the title editor is open AND the trimmed draft is empty, THE SYSTEM SHALL mark the input aria-invalid and display a visible message, and SHALL clear both as soon as the trimmed draft is non-empty.
• AC-57: WHILE the title editor is open, WHEN the user opens the description editor, THE SYSTEM SHALL close the title editor, discard its draft, restore its frozen baseline title, and send no request.

Documentation reconciliation

• AC-32: docs/specs/office/tasks.md SHALL be amended so that its editable-property list at ### D. Inline editable properties names Title and Description, and its PATCH /tasks/:id entry under ## API surface states that title and description are edited through PATCH /api/v1/tasks/:id and are not fields of the Office endpoint. No other behaviour in that document changes.

Surfaces touched

• apps/web/components/task/simple/OfficeSimplePane.tsx: the <h1> at line 512 and the description block at lines 513-517. The component is 574 lines against a 600-line lint ceiling, so the editors are expected to be extracted into sibling components rather than added inline.
• AC-25's data source is already in scope: OfficeSimplePaneProps declares sessions: TaskSession[], and TaskSession["state"] already includes "RUNNING". No new fetch, prop, or store field is required for the running-session note.
• apps/web/hooks/use-optimistic-task-mutation.ts: toOfficeTaskPatch must carry title and description, and the section E rules apply to the store patch it writes. This hook does not fit both fields as it stands, and that is expected, not a defect to work around. Its only shape is apply-patch-then-await: it calls ctx.applyPatch and patchTaskInStore before await apiCall(), and on failure restores the whole storeSnapshot. That matches the title (optimistic at issue time, AC-11) and does not match the description (store patch on success only, AC-56), and its whole-object rollback is wrong for both (AC-55 requires a field-scoped restore). Build is expected to reshape or extend the hook rather than silently accept pre-await timing for the description; which of the two it is is an implementation decision, but the timings in AC-11 and AC-56 and the field-scoping in AC-55 are not.
• apps/web/app/office/tasks/[id]/page.tsx: refetchTask replaces the whole task object, so the per-field in-flight guard from section E is applied here. It carries no request ordering of any kind today, and useOfficeRefetch (apps/web/hooks/use-office-refetch.ts) has no debounce, no coalescing and no in-flight cancellation, so concurrent refetches for one task are the normal case rather than an edge case. That is why AC-60 exists.
• apps/web/lib/ws/handlers/office.ts: the second store writer. normalizeIssueFields (the p.title / p.description mapping) and updateTaskStatus (the raw store.setState) are both in scope, because together they write these two fields into the Office task store outside patchTaskInStore. AC-61 governs. Prior art for the ordering half of section E, worth reading before implementing it: nextRequestSequence / isLatestRequest in apps/web/hooks/use-office-workspace-data.ts already give every other Office loader last-request-wins, for exactly this reason.
• apps/web/lib/api/domains/kanban-api.ts: updateTask(), used as-is. Note its return value is now load-bearing: it resolves to the updated Task, and AC-58 records that response's value for the written field as canonical. A call site that discards the response cannot satisfy AC-58.
• docs/specs/office/tasks.md: reconciliation per AC-32.
• i18n: new copy in en plus pt-pt, zh-cn, zh-hk, zh-tw. common:save, common:cancel, task:description, task:taskTitle, task:saving, task:updateFailed and office:addADescription already exist and should be reused rather than duplicated. One trap: task.json carries both description (value "description", lowercase, used today as an inline KeyValueRow label) and description2 (value "Description", capitalized). Pick by the element: a standalone visible label wants task:description2, an inline or aria-only string wants task:description. Do not add a third key for the same word.

No backend file changes are required by this spec. AC-48 adds a test over existing backend behaviour; it does not change it.

Test expectations

Every acceptance criterion has a declared verification below. AC ids are enumerated individually rather than as ranges, so coverage can be checked mechanically: every id from AC-1 to AC-73 appears at least once in this section.

• Unit (vitest), alongside apps/web/components/task/simple/OfficeSimplePane.test.tsx:
  • Title editor open / commit / cancel / blur / clamp / paste-clamp / empty / unchanged / IME paths: AC-1, AC-2, AC-4, AC-5, AC-6, AC-7, AC-8, AC-10, AC-33, AC-37.
  • Title trim on send and on optimistic render: AC-3.
  • Title rollback, all four branches of the sequence rule, one test each: the last-word-standing case with no later commit at all (AC-9); a later commit that already succeeded (AC-44); a later commit still unresolved (AC-53); and a later commit that already resolved with failure, which restores (AC-65). AC-53 is the branch whose absence previously made AC-9 mandate the wrong outcome, and the fourth branch is the one whose absence let a chained double failure land on a never-persisted title, so both are asserted explicitly and neither is folded into AC-9's test.
  • The rollback target (AC-64): a failed commit restores the title's currently recorded canonical value, not a value captured from the display at commit-issue time. Assert this directly, with a canonical value that differs from what was displayed when the commit was issued, so a snapshot-based implementation fails.
  • The chained double failure, asserted in both resolution orders (AC-65). Two overlapping title commits, both failing: assert the displayed title and the Office task store entry both end at the canonical (pre-chain, actually stored) title when the earlier commit resolves first, and again when the later one does. This is the regression test for the defect the four-branch partition and AC-64 were written to close; a test that runs only one resolution order would have passed against the broken spec.
  • Office task store patch mapping, and the timing split between the two fields: AC-11 (title patched at commit-issue time, asserted before the request resolves) and AC-56 (description not patched at issue time, patched on success).
  • Field-scoped store rollback on a failed title commit: AC-55 asserts the store entry's title is restored and that a second field of the same store entry, changed in the meantime, is not.
  • The title's frozen baseline under a canonical update: AC-51.
  • Description open / placeholder / dirty / Save / Cancel / confirm / blur / Escape paths: AC-12, AC-13, AC-14, AC-15, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AC-23, AC-24, AC-34, AC-36.
  • Frozen baseline under a refetch: AC-40. Draft survives a refetch while open: AC-28.
  • In-flight control state and in-flight editing: AC-41, AC-42.
  • Whitespace-only draft on an empty description: AC-43.
  • No length limit and plain-text rendering: AC-45, AC-46.
  • Running-session note: AC-25.
  • In-flight guard for the optimistic title, editor closed and unrelated-mutation refetch: AC-38, AC-39.
  • The canonical/displayed rules from section E, one test each: recording is never suppressed (AC-49); the deferred apply fires when the guard releases, asserted through the case that motivated it, a remote description edit arriving during an open editor that the user then cancels (AC-50); a response whose request predates the local write is discarded rather than recorded (AC-52).
  • The three record triggers, enumerated in section E. The initial load records both fields (AC-59). A successful write records the value its own response persisted, asserted before the guard releases (AC-58). The regression this pair exists to prevent is asserted directly and on both fields: with no refetch in play at all, a successful title commit and a successful description save each leave the displayed value at the saved text after the guard releases, rather than reverting to the pre-write value.
  • The updated_at ordering rule, one test per branch: two refetches resolving out of order leave the newer value in place (AC-60); a refetch issued after a commit but carrying an older updated_at than the commit's own response is discarded (AC-62); two candidates with exactly equal updated_at resolve by request-issue sequence (AC-63).
  • Cross-format parsing (AC-66). The fixtures must be the two layouts that actually occur, not two variants of one: a refetch recording in the Office task DTO's raw SQLite form (2026-08-20 14:30:05.123456789+00:00, space-separated and offset-suffixed) and a write-response recording in RFC3339Nano (2026-08-20T14:30:05.123456789Z). Assert the ordering comes out right in both directions. A raw string comparison must fail this test, and so must an implementation that parses only the T/Z form, and so must one that hands the space-separated form to new Date(...) and assumes local time. AC-60's earlier prescribed fixtures (one RFC3339Nano value with a stripped trailing zero and one at second resolution) exercised only the same-format hazard and would have passed against a parser that is wrong for the majority of real comparisons; keep one such pair as an additional case, but it is not the primary one.
  • The seed rule (AC-72): with no canonical value recorded for a field, the next candidate is recorded even when it would fail the staleness, ordering or parse rule, so a failed commit always has a restore target (AC-64). And (AC-73) where the seed's updated_at did not parse, a later candidate whose updated_at does parse supersedes it, so the field is not pinned to the seed for the lifetime of the page.
  • Unparseable updated_at (AC-67): a candidate whose timestamp does not parse is discarded for that field, the previously recorded canonical value survives unchanged, and the candidate is not treated as newest. Assert the surviving value explicitly, because a "fall back to now" implementation passes any test that only checks the candidate was not recorded verbatim.
  • Guard lifetime (AC-68, AC-69, AC-70). Unmounting the detail page while an editor is open leaves the field unguarded, so a subsequent office.task.updated reaches the store entry (AC-68). A write that resolves after unmount still records its canonical value and still ends its contribution, and the store entry ends at the persisted value (AC-69). A failed write ends its contribution exactly as a successful one does, asserted by showing that a later event reaches the store entry after the failure (AC-70). These three are the tests that would catch a guard implemented as an independently-mutated flag rather than derived from its two facts.
  • Absent-description normalisation (AC-71): on a task with no description, a guard release applies nothing and fires no store patch, with the load path supplying description: undefined and the write path supplying "". Without normalisation the two compare unequal and the test sees a spurious apply.
  • The WebSocket handler is subject to the guard (AC-61): with a title commit in flight, an office.task.updated carrying the pre-commit title leaves the Office task store entry unchanged. This test must drive the real office.ts handler path (normalizeIssueFields plus updateTaskStatus), not patchTaskInStore, or it asserts nothing.
  • Convergence after two overlapping title commits that both succeed, with the responses delivered out of order: AC-54.
  • Both editors independent, title commits while description draft is dirty: AC-35. And the other order, which is the asymmetric one: opening the description editor while the title editor is open closes the title editor and discards its draft (AC-57).
  • No status or lifecycle gate, and no archived gate: AC-30, AC-47.
  • Only the edited field is sent, single-writer case: AC-26.
• Backend (Go), alongside apps/backend/internal/task/service/:
  • A description-only update on a task carrying a pending agent title leaves the pending metadata and the stored title intact: AC-48. This exercises the conditional title statement in updateTaskTx described in section F.
  • A title update on a task carrying a pending agent title persists the human title and clears the pending metadata: AC-29.
  • A title or description update publishes task.updated without assignee_agent_profile_id on the payload, so queueTaskAssignedRun cannot queue a run: AC-31. This is the regression test that makes AC-31 a contract rather than a code-reading, and it fails the moment somebody adds that field to publishTaskEventNow.
• E2E (Playwright), a new spec alongside apps/web/e2e/tests/office/property-pickers.spec.ts:
  • Editing the title and the description on a real seeded Office task, asserting both the rendered value and the persisted row: AC-3, AC-16, AC-17, AC-26.
  • A second browser context observing the edit converge without a reload: AC-27.
  • One route-mocked failure asserting title rollback: AC-9.
  • One route-mocked failure asserting the description editor survives with its draft intact: AC-18.
• AC-32 is a documentation change with no runtime behaviour. It is verified by inspection of docs/specs/office/tasks.md in the same pull request; Build must confirm both edits landed.

Out of scope

Each exclusion below is a decision, not an omission.

• General optimistic concurrency control on task writes. Service.UpdateTask keeps last-commit-wins for every column except the title compare-and-swap that already exists and is described in section F. Adding a version column or an updated_at precondition for the remaining columns would alter every existing caller of the endpoint and belongs in its own card. This feature neither adds nor removes concurrency control in the backend.
• Guaranteeing which of two rapid renames wins. Sequence numbers order this client's rollbacks; they do not order the network, and this feature adds no wire ordering, no re-send, and no server-side arbitration. Two overlapping title commits resolve to whichever write the server committed last, and the display converges on it (AC-54). A caller who needs a defined winner is asking for the concurrency control excluded above.
• Description version history, undo, or drafts persisted across page loads. Explicit Save exists precisely because none of these do. A draft lives in component state and is lost on navigation or reload.
• Markdown rendering or a rich-text editor for the description. The field stays plain text with preserved whitespace, exactly as it renders today. AC-46 pins this.
• Extending PATCH /api/v1/office/tasks/:id to accept title or description. The Office endpoint and its hasAnyField() guard are unchanged, and a {"title": "..."} body sent to it continues to return 400 "no mutation fields supplied".
• Waking or re-prompting the assigned agent on a content edit. Deliberately not done; see section D. Making a description edit re-brief a running agent is a product decision with its own failure modes and needs its own spec.
• A minimum or maximum length for the description, and any change to the 60-character title limit.
• Editing title or description anywhere else in Office: the task list, board cards, the sidebar, the inbox, and the advanced / dockview mode are untouched.
• The sidebar property pickers. They auto-save optimistically by design (docs/specs/office/tasks.md:60) and are E2E-proven. No Save button is added to them.
• The blank Created by / Started / Completed rows. Tracked separately.
• An archived-task gate. Not an exclusion of behaviour but of a gate: the Office detail page renders no archived state and the backend enforces no archived precondition, so no gate is added and the Kanban isArchived condition is not ported. See section A and AC-47. Introducing archived semantics to this page is separate work.