Merge master and reconcile skill preparation optimizations

Preserve installed-selection reuse and bundled relocation together with metadata-only package preparation. Retain both cleanup notifications, use the hardened upstream editor test, and regenerate unchanged skill SQL as migration 0414.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

maps/agent-access-map/agent-chat.md

@@ -48,6 +48,8 @@ API: `present` — representative operation IDs:
 
 - `GET /api/issues/{id}/comments`.
 - `POST /api/issues/{id}/comments`.
+- `GET /api/issues/{id}/decision-receipts` (own standing-chat board read).
+- `GET /api/issues/{id}/chat-handoffs` (own standing-chat board read, paginated).
 
 Agent access: `partial` — Assigned conversation task tools / REST for eligible task
 history and replies.
@@ -66,6 +68,18 @@ remaining operations before qualifying the whole capability.
 Gaps: Agent responses are supported; creating the person's chat and impersonating their
 messages are different actions.
 
+Coordinator model/effort selection reuses `PATCH /api/issues/{id}` for the conversation's `assigneeAdapterOverrides`, followed by the existing idempotent board-user comments endpoint. It introduces no new route or actor authority and never changes the agent configuration. Settings and message admission are separate writes: a settings failure prevents submission; a later message failure may leave the selected conversation settings saved. Existing in-flight execution is not retroactively changed. UI tests cover ordering and first-message identity; provider/session behavior remains a separate live check.
+
+Coordinator evidence: [canonical chat projections](../../server/src/services/conversation-decision-receipts.ts)
+return stable references to recorded task/decision rows, not copied agent prose.
+The caller must own and currently read the source conversation; source agent and
+session generation must still match the handoff, and each target task must remain
+readable. The projection does not give the coordinator new execution authority or
+wake it merely to repeat a human decision. The normal local-implicit/admin access
+exception remains unchanged.
+
+`GET /api/issues/{id}/pending-questions` is a board-owned, read-authorized projection of canonical attention, limited to current chat handoffs plus ordinary tasks created by the caller and currently assigned to that chat’s agent. Direct tasks with any existing chat handoff are excluded from the direct-task branch. The same direct-task scope extends recorded-decision reads from the current chat boundary; pending direct-task questions remain actionable across resets. Question audience, dismissal, archive, snooze and task privacy come from the existing attention service. No copied interactions or new write authority are introduced. The read currently obtains one full authorized company attention snapshot when relevant tasks exist; no polling is added.
+
 ## `handoff`
 
 Capability ID: `agent-chat/handoff`.
@@ -76,6 +90,8 @@ API: `present` — representative operation IDs:
 
 - `POST /api/companies/{companyId}/projects`.
 - `POST /api/companies/{companyId}/issues`.
+- `POST /api/issues/{id}/interactions` with `suggest_tasks`.
+- `POST /api/issues/{id}/interactions/{interactionId}/accept`.
 
 Agent access: `available` — Native list_projects/create_project/create_task; project MCP
 tools; REST.
@@ -94,6 +110,15 @@ remaining operations before qualifying the whole capability.
 Gaps: Agent handoff is implemented; execution readiness, assignment permission, and
 repository access still apply.
 
+Coordinator evidence: [interaction service](../../server/src/services/issue-thread-interactions.ts)
+accepts authorized chat proposals through the normal issue creation service,
+with atomic initial-plan persistence and a durable originating-chat handoff.
+New chat handoffs default to the conversation agent when no agent or person is supplied. The effective default is included in assignment authorization before creation; explicit assignments retain company, invokability and access checks. Raw REST derives the default only from a verified same-company, same-agent run-bound conversation. Native/MCP creation and accepted suggestions follow the same owner policy. Suggestions alone have no task-creation effect. Accepted chat roots are standalone
+tasks; nested execution tasks retain normal parent/child rules. Source participant,
+session generation, task assignment and private-source inheritance are checked;
+quality confirmations remain separate from task completion and publication.
+[Focused regression coverage](../../server/src/__tests__/coordinator-handoff.test.ts)
+does not claim live model/tool selection or external delivery verification.
 Additional coverage: the explicit [chat feature evals](../../tests/runner-e2e/CHAT-FEATURES.md)
 exercise native task creation and completion delivery through the real chat UI.
 The [chat directive](../../server/src/services/agent-conversations.ts) tells agents
@@ -127,3 +152,9 @@ remaining operations before qualifying the whole capability.
 Gaps: Not callable through generic REST tooling: protocol and deployment constraints
 apply. This route is not guarded by assertBoard, so its intended agent policy needs
 clarification.
+
+### Required quality-review handoff
+
+`request_human_input` suggestions and native `create_task` accept the same optional `requiredQualityReview` contract; task creation persists it atomically. Execution uses existing confirmation/item-verdict interactions with explicit quality-review keys and exact document/attachment targets. The server stamps the current requirement fingerprint, forces human-only resolution, validates current targets, and independently prevents completion until every required output has human approval. Agents cannot remove or weaken an existing requirement. Existing task read/write company and actor checks remain authoritative. Publication/delivery authority is unchanged. Completion-only chat wakes receive bounded canonical decision references and guidance to reuse reviews, not start duplicate ones.
+
+An attachment target is an exact immutable identity, not a mutable latest-output label. Registering another attachment does not automatically replace that required slot; the agent must request a fresh bound review for the replacement. Deduplicated task creation rejects a mismatched requested review contract, and an already-completed task must reopen before taking an unsatisfied requirement.

maps/agent-access-map/documents-artifacts.md

@@ -16,6 +16,15 @@ for format, permission checks, evidence and maintenance.
 
 Capability ID: `documents-artifacts/documents`.
 
+Coordinator receipt reads add `GET /api/issues/{id}/documents/{key}/revisions/{revisionId}`.
+It applies the same task-read authorization as document revision history and
+queries exactly one revision under that task/document key. It does not fall back
+to current content. Cross-task receipts retain both the originating interaction
+and document owner; sidebar reads use the owner's existing authorization boundary.
+The [document service regression](../../server/src/__tests__/documents-service.test.ts)
+checks exact identity and cross-key/task misses against temporary PostgreSQL;
+route and live caller authorization remain separately verified.
+
 Review: `baseline`.
 
 API: `present` — representative operation IDs:

maps/agent-access-map/inbox-search.md

@@ -105,6 +105,27 @@ API: `present` — representative operation IDs:
 
 - `GET /api/companies/{companyId}/decision-queues`.
 - `GET /api/companies/{companyId}/decision-queues/{key}/items`.
+- `GET /api/companies/{companyId}/attention/history` — read-only canonical
+  interaction/Decisions-v1 projection with cursor, search, outcome, agent, project,
+  date, and chronological sort filters. Each source and v1 target must pass task
+  privacy checks. Bounded to 100 records per page; no second decision write store.
+
+The history route is **operator-only**: a board user with company access is
+required. It does not grant an agent resolver authority. Existing task interaction
+and decision routes remain the mutation owners. Source evidence:
+[history service](../../server/src/services/decision-history.ts) and
+[route](../../server/src/routes/attention.ts). Real temporary PostgreSQL regression
+coverage is in [decision-history.test.ts](../../server/src/__tests__/decision-history.test.ts);
+this is not a deployed user/agent credential test.
+
+`GET /api/companies/{companyId}/attention` also projects existing pending
+interactions from persistent agent chats, including `ask_user_questions`, under
+the same board, company, task-read, and addressee rules. The execution-container
+exclusion does not suppress an explicit human request. Resolution still uses
+the owning interaction API and its resolver policy; ordinary chat prose and idle
+review status do not become decision records. Source and isolated PostgreSQL
+coverage: [attention service](../../server/src/services/attention.ts) and
+[regressions](../../server/src/__tests__/attention-service.test.ts).
 
 Agent access: `partial` — REST / native call_api under decision queue authorization.
 

maps/agent-access-map/navigation-preferences.md

@@ -50,6 +50,8 @@ API: `present` — representative operation IDs:
 
 - `GET /api/sidebar-preferences/me`.
 - `PUT /api/sidebar-preferences/me`.
+- `GET /api/workspace-preferences/me`.
+- `PUT /api/companies/{companyId}/workspace-preferences/me`.
 
 Agent access: `restricted` — Board-user preference API; browser section collapse.
 
@@ -67,6 +69,23 @@ own policy and access review.
 Gaps: Catalog metadata says board_or_agent, but requireBoardUserId rejects agents.
 Collapse is in-memory; global collapse is disabled.
 
+Personal workspace addition: the [workspace preference route](../../server/src/routes/workspace-preferences.ts)
+is board-only and selects the owner from the actor, never the body. Active viewers
+may update their own choice with validated company audit context; local-trusted
+uses `local-board`. The setting is instance-personal, not an execution capability.
+The UI explains the separate Agent Chat prerequisite; the preference endpoint
+does not enable it or grant access to instance settings.
+[Route tests](../../server/src/__tests__/workspace-preferences-routes.test.ts) cover
+agent/anonymous denial and foreign/inactive company rejection. Database and browser
+checks remain separate from route authorization; no agent delegation path exists.
+
+Coordinator navigation pins are a separate browser-local presentation preference
+owned by [usePinnedNavigation](../../ui/src/hooks/usePinnedNavigation.ts). They store
+allowlisted route names by user, across companies, and have no API or agent delegation
+path. Pinning does not grant access to the destination; existing route permissions
+still apply. Component tests cover identity scoping and cross-tab updates, separately
+from live authenticated-user verification.
+
 ## `profile`
 
 Capability ID: `navigation-preferences/profile`.

maps/agent-access-map/onboarding.md

@@ -96,6 +96,11 @@ testing an existing agent; interactive account login additionally requires a
 board user and owner-bound session. An agent's right to hire is not login or
 instance-environment administration authority.
 
+A name-only, held setup has no provider selection yet, so the wizard omits its
+runner choice until the provider is chosen. The existing board-only setup and
+saved-agent update permissions remain; normal runner compatibility validation
+is unchanged. No runnable legacy fallback is created.
+
 Scoped source-only runtime preparation: the existing authorized adapter test
 prepares the default Claude CLI in its already acquired sandbox when the image
 version is too old for the selected model. It installs a pinned package into a

maps/feature-map/agent-chat.md

@@ -25,9 +25,13 @@ Agent access: [companion](../agent-access-map/agent-chat.md).
 
 Open `/chats`, choose an agent, or use `/chats/:agentRef` and its conversation sidebar.
 
+With Coordinator enabled, the composer exposes the shared model/thinking-level picker for supported agents. The agent stays fixed in this control; switching agents remains in the chat header. Choices save as conversation overrides on send, preserving the agent's configuration. A first message creates the conversation before saving settings and submitting through the ordered comments endpoint.
+
+Coordinator answer receipts from this conversation jump to the answer bubble without leaving chat. Answer updates from an execution task link to that source task and its decision context. Compact document links read “Open [document title] in the sidebar”.
+
 ### `project-handoff`
 
-Ask for project work in Agent Chat and follow its created project/task links.
+Ask for project work in Agent Chat and follow its created project/task links. New tasks and accepted task suggestions default to the agent in that conversation. An explicitly requested agent or person takes precedence; no best-fit agent routing is inferred. Ordinary task creation outside chat keeps its existing assignment behavior.
 
 ### `conference-room`
 
@@ -41,6 +45,12 @@ Preconditions: follow the [baseline](./README.md#before-driving-a-journey). Enab
 
 Automated: [chat landing](../../ui/src/pages/AgentChats.test.tsx) checks recent-chat routing; [conversation service](../../server/src/__tests__/agent-conversations.test.ts) covers persisted conversation behavior.
 
+Automated: [composer picker](../../ui/src/components/task-chat/ComposerRunSettingsPicker.test.tsx) covers fixed-agent model/effort selection on desktop and mobile; [composer](../../ui/src/components/task-chat/TaskChatComposer.test.tsx) covers Coordinator gating and settings submission without reassignment. [Task detail](../../ui/src/pages/IssueDetail.test.tsx) verifies canonical first/existing-chat IDs, settings-before-comment ordering, and no comment submission when settings fail to save. These tests mock the API and do not prove provider execution with the chosen model.
+
+Automated: [conversation delivery](../../server/src/__tests__/agent-conversation-delivery.test.ts)
+checks that paused or otherwise non-invokable agents leave comments pending
+without aborting startup recovery, and that a later unpause allows one delivery.
+The test persists queue admissions only; it does not start agents or providers.
 Automated: [historical chat](../../ui/src/pages/AgentChat.test.tsx) keeps an older
 conversation reachable after a cached roster refresh ends in HTTP 429. It checks
 lookup Retry and preserves permission and company boundaries. This is component
@@ -66,6 +76,13 @@ inaccessible saved conversation; verify no cross-user or cross-company history a
 
 Automated: [chat project tools](../../server/src/__tests__/chat-project-tools.test.ts) checks tool contracts; live model choice and UI handoff require a manual run.
 
+Automated: [Coordinator handoffs](../../server/src/__tests__/coordinator-handoff.test.ts)
+checks that a suggested task remains a proposal until acceptance, that its task,
+initial plan and source-chat audience are saved atomically, and that retries do
+not create another task. A conversation is a privacy/provenance source rather
+than a structural task parent. The same tests cover compact canonical decision
+receipts, exact uploaded-artifact bindings, current task access, reset-session
+boundaries, and pagination of older handoffs.
 Explicit live evals: [chat feature journeys](../../tests/runner-e2e/CHAT-FEATURES.md)
 send natural requests to save a backlog task or delegate an announcement. They
 check project/assignee, execution or non-execution, saved output, return to chat,
@@ -75,6 +92,17 @@ task links unless the platform supplied a verified absolute origin.
 
 Manual: Ask the configured agent to create bounded project work, inspect the proposed/created target, and open the resulting task. Verify the request context and intended project survived and the task produces a useful output.
 
+Manual: With the personal Coordinator workspace enabled, discuss a vague request
+until the agent suggests a task. Confirm that no execution task exists before
+acceptance. Accept it, stay in chat, and open the created card on demand. An
+explicit request to create a task may create it directly under normal authority.
+Approve a work product or answer a question in its task or Needs You, then return
+to the originating chat. Its compact update should link to the exact recorded
+decision and reviewed artifact, without needing another coordinator turn.
+Approval of artifact quality alone must not publish it or complete the task.
+
+Coordinator task clarification: create a task with only a description. When material context is missing, native task guidance asks one focused canonical question inside that task. Its actionable form is also projected into Needs You and the originating standing chat; direct user-created tasks appear in the assigned agent’s standing chat. Answer on either surface and verify the pending card/count clear and a compact recorded answer replaces it in chat. This projection is event-refreshed and does not wake another agent merely to repeat the question. Current direct-task questions survive a chat reset; their answered receipts start at the current chat boundary. The task brief remains editable context, not another stored question. Model choice and actual resumed execution still require live verification.
+
 ### `conference-room`
 
 Automated: [board chat gate](../../server/src/__tests__/board-chat-route-feature-flag.test.ts) proves route gating, not a live conversation.
@@ -87,6 +115,8 @@ Manual: Check disabled access first, enable in the disposable instance, then sen
 
 ## Gotchas
 
+- Coordinator Markdown references to a standing agent conversation display “Chat with [agent]” and route to that chat, preserving anchors. Labels resolve once from the existing current-person/current-company chat list and agent roster; no task status glyph or task quicklook is shown for these references. Ordinary task links retain their existing treatment.
+
 - Idle chat is not failed execution.
 - See [steering](./steering.md) for in-flight messages and [questions](./questions-and-approvals.md) for interactions.
 - An API tool test does not prove that every harness will choose the same handoff tool.
@@ -101,3 +131,11 @@ Scope: ui
 Storybook: Conference-room flag disabled, empty/history/reply, busy and explicit failure states.
 Production: Exercise separate BoardChat route gate, local-trusted deployment and authenticated Claude CLI; send/reload real conversation with responding agent attribution.
 Sources: Source: [BoardChat.tsx](../../ui/src/pages/BoardChat.tsx), [board-chat.ts](../../server/src/routes/board-chat.ts). Tests: [BoardChat.test.tsx](../../ui/src/pages/BoardChat.test.tsx), [board-chat-route-feature-flag.test.ts](../../server/src/__tests__/board-chat-route-feature-flag.test.ts)
+
+### Explicit output quality review (Coordinator functional slice)
+
+Accepted suggestions and native explicit task creation may carry `requiredQualityReview` into the task's existing execution policy. The opt-in requirement names output slots and is separate from the existing reviewer eligibility policy. Each slot requires a canonical human verdict bound to an exact current output document revision or attachment identity. Plans, questions, file presence, model completion claims, rejected/deferred verdicts and stale versions do not satisfy it. Only a human may change an existing requirement. Quality approval does not publish or automatically complete the task. Tasks without this optional requirement retain existing completion behavior.
+
+Owning service: `server/src/services/required-quality-review.ts`; enforcement: interaction creation, issue update, native completion feedback/finalization. Focused proof: `server/src/__tests__/required-quality-review.test.ts` plus native arbiter and chat completion delivery tests. Completion updates include bounded canonical output-decision identities for linking existing review, never worker-authored review prose. These tests do not establish unattended live provider reliability.
+
+Attachment approval is for the exact immutable file identity. Removal or a mismatched hash invalidates that target; registering a replacement beside the approved file does not redefine its output slot. A replacement requires a fresh bound review. Document targets additionally track the current revision.

maps/feature-map/documents-artifacts.md

@@ -26,6 +26,14 @@ Agent access: [companion](../agent-access-map/documents-artifacts.md).
 
 Open a document from the task thread or document side panel.
 
+Coordinator decision receipts also open a pinned reviewed revision alongside
+the matching task interaction. Historical tabs retain their revision identity
+independently of the current document tab. Missing revisions are explicit and
+never silently replaced with the latest document.
+When a decision in one task reviews another task's document, the center pane
+keeps the originating conversation while the sidebar opens the document owner's
+exact revision. An inaccessible owner never falls back to the origin task's document.
+
 ### `task-output`
 
 Open an attachment, output card, or file link from a task.
@@ -45,6 +53,11 @@ Preconditions: follow the [baseline](./README.md#before-driving-a-journey). Use
 
 Automated: [documents service](../../server/src/__tests__/documents-service.test.ts), [annotations](../../server/src/__tests__/document-annotations-service.test.ts), and [revision restore](../../server/src/__tests__/issue-document-restore-routes.test.ts) cover server contracts.
 
+[Exact revision panel](../../ui/src/components/task-side-panel/TaskDocumentPanel.test.tsx)
+checks pinned content and missing-revision behavior; this component test does not
+prove end-to-end conversation scrolling. Open a resolved receipt after making a
+new revision and verify the earlier body plus matching interaction in the browser.
+
 Manual: Edit a paragraph, save, reload, and compare revisions. Add an annotation to a specific selection and inspect it after another edit. Resolve it through the supported action. Restore a disposable revision and confirm the new current document and history agree.
 
 ### `task-output`
@@ -67,6 +80,8 @@ Manual: Find the task’s output through search and grouping, open its stack, pa
 
 ## Gotchas
 
+- In Coordinator, saved plan cards use document chronology, so a plan written before its output appears first even when both writes share one native run. Authored issue-document links use the same compact sidebar-link surface and retain revision/annotation targets. Classic run embedding is unchanged. The UI does not remove or deduplicate canonical plan content.
+
 - A local path is not automatically an uploaded artifact accessible to another user.
 - A preview screenshot is not proof that download bytes or revision references are correct.
 - Version conflicts and stale annotations must stay visible rather than silently targeting different content.

maps/feature-map/inbox-search.md

@@ -30,6 +30,26 @@ Use Inbox links or the corresponding task views when the combined list is enable
 
 Open `/decisions`, then a queue at `/decisions/queues/:key` and its source item.
 
+With **Settings → Experimental → Coordinator workspace** enabled, `/decisions`
+is **Needs You**. Pending cards use the existing attention feed and canonical
+resolvers. **Tasks → Needs attention** projects the same feed as distinct tasks.
+Search, filter by agent/project, sort, and group by task/agent/project apply to
+both open decisions and the visible Recent Decisions receipts. Successful
+resolutions resize into compact receipts while the same contained Gather Light
+effect used for task creation runs concurrently. The receipt stays in its card
+position until that treatment finishes, then settles under **Recent Decisions**.
+Motion follows the saved history result; failed saves retain the actionable card,
+reduced motion settles immediately, and revisiting history does not replay it. The initial
+24-hour display window is an experimental assumption, not data deletion.
+Resolving an artifact decision does not itself complete its task. If the task
+remains in review without a maintained reviewer or continuation, its separate
+canonical stalled-review item stays in Needs You and Tasks → Needs attention.
+Coordinator presents the existing recovery actions with **Mark task done** as
+the task-level verdict, distinct from the saved artifact receipt.
+
+Open **Decision history** on this surface for the paginated history sidebar;
+it merges answered questions and confirmations with Decisions-v1 outcomes.
+
 ### `search`
 
 Open `/search` or the navigation search entry.
@@ -82,6 +102,26 @@ Automated: [decision queues](../../server/src/__tests__/decision-queues-routes.t
 
 Manual: Open a pending decision, follow its source, resolve it through the supported control, and reload the queue. Confirm it retires only after the decision persisted and unrelated pending items remain.
 
+Coordinator regression sources: [canonical history](../../server/src/__tests__/decision-history.test.ts)
+exercises real PostgreSQL cross-source pagination, answered-question retention,
+company/private-task isolation, and private v1 targets.
+[Attention service regressions](../../server/src/__tests__/attention-service.test.ts)
+cover pending question forms and confirmations in persistent agent chats, removal
+after an answer with retained history, and company/task-visibility/addressee checks.
+Idle chats without structured requests remain absent. The
+[Needs You component test](../../ui/src/components/coordinator/CoordinatorNeedsYou.test.tsx)
+checks that a chat-sourced canonical question reaches its original resolver and context.
+It also checks simultaneous resize/light and delayed movement to Recent Decisions.
+[Shared card-motion tests](../../ui/src/components/coordinator/CoordinatorTaskCommitment.test.tsx)
+cover reduced-motion settlement and returning to a resolved card without replay.
+The [decision-motion stories](../../ui/storybook/stories/design-proposals/coordinator-decision-motion.stories.tsx)
+exercise real Needs You/resolver components with isolated approval, question, and failed-save responses.
+[Projection helpers](../../ui/src/lib/coordinator-attention.test.ts) cover distinct
+pending task membership and presentation-only recency decay. Browser verification
+must additionally approve copy, approve a visual, and answer a question; confirm
+three retained receipts, task/chat consistency, resize/collapse motion, and exact
+task context on receipt click. Turning the setting off restores the classic surface.
+
 ### `search`
 
 Automated: [search page](../../ui/src/pages/Search.test.tsx) and [company search service](../../server/src/__tests__/company-search-service.test.ts) cover UI and server search separately.
@@ -148,3 +188,5 @@ Scope: ui
 Storybook: Eligible live task toast, explicit mention, quiet unrelated event, own-action/visible-task suppression, dedupe and company/account switch.
 Production: Persisted participation and mentions determine per-viewer socket eligibility; quiet events still refresh caches; reload retains eligibility, unauthorized resources remain denied.
 Sources: Source: [ToastViewport.tsx](../../ui/src/components/ToastViewport.tsx), [ToastContext.tsx](../../ui/src/context/ToastContext.tsx), [LiveUpdatesProvider.tsx](../../ui/src/context/LiveUpdatesProvider.tsx), [task-toast-eligibility.ts](../../server/src/realtime/task-toast-eligibility.ts). Tests: [ToastContext.test.tsx](../../ui/src/context/ToastContext.test.tsx), [ToastViewport.test.tsx](../../ui/src/components/ToastViewport.test.tsx), [LiveUpdatesProvider.hook.test.tsx](../../ui/src/context/LiveUpdatesProvider.hook.test.tsx), [task-toast-eligibility.test.ts](../../server/src/__tests__/task-toast-eligibility.test.ts), [live-events-toast.test.ts](../../server/src/__tests__/live-events-toast.test.ts), [multi-user-authenticated.spec.ts](../../tests/e2e/multi-user-authenticated.spec.ts)
+
+Coordinator navigation counts all outstanding canonical attention items on desktop and phone, using the same complete feed as Needs You. Classic keeps its existing today-oriented badge. Task questions resolve through their original interaction; pending chat projections, counts and recorded receipts invalidate together.

maps/feature-map/navigation-preferences.md

@@ -15,7 +15,7 @@ Agent access: [companion](../agent-access-map/navigation-preferences.md).
 ## Sub-features
 
 - `navigation`: `navigation-preferences/navigation` — use current sidebar links, favorites, recents, and available layout controls.
-- `preferences`: `navigation-preferences/preferences` — persist supported ordering/collapse choices for the intended user/company.
+- `preferences`: `navigation-preferences/preferences` — persist supported ordering/collapse choices for the intended user/company, and the personal experimental workspace choice.
 - `profile`: `navigation-preferences/profile` — edit personal identity and inspect public profile links.
 - `announcements`: `navigation-preferences/announcements` — inspect and dismiss an announcement with its intended instance-wide user scope.
 - `fallbacks`: `navigation-preferences/fallbacks` — handle missing resources and old deep links without presenting another resource as the target.
@@ -99,3 +99,45 @@ IDs per company/account without passive full-detail or workspace inspection.
 Successful omissions remove unavailable entries; failed reads preserve history.
 Verify rename, inbox archive, pause/restart, reload, cross-tab updates and account
 switches. Inbox archive does not remove the task from recent history.
+
+### Personal Coordinator workspace
+
+Settings → Experimental → Coordinator workspace opts the current person into the
+experimental shell; off restores classic. The server saves the choice by user across
+companies, separate from instance feature flags. The local-trusted identity is shared
+Local Board, not evidence of multi-user isolation.
+Agent Chat remains an independent instance prerequisite. When it is off, the
+personal card explains the dependency and links eligible instance administrators
+to the existing Agent Chat control. Hidden or Cloud-managed controls are not
+presented as editable. Disabled Chat routes link back to Experimental settings.
+Enabling the personal workspace never changes the instance capability.
+
+Automated: [preference hook](../../ui/src/hooks/useCoordinatorWorkspaceEnabled.test.tsx),
+[prerequisite settings card](../../ui/src/components/CoordinatorWorkspaceSetting.test.tsx),
+[authorization](../../server/src/__tests__/workspace-preferences-routes.test.ts), and
+[database persistence](../../server/src/__tests__/workspace-preferences.test.ts).
+Manual: toggle on/off, reload, switch companies/accounts, and simulate failed reads
+and saves. Confirm existing work is unchanged and a failed save keeps the current
+choice. The [Settings card story](../../ui/storybook/stories/navigation-preferences/coordinator-workspace-setting.stories.tsx)
+uses the production component with simulated API responses; it does not establish
+real persistence or permission behavior.
+
+Local browser verification (2026-10-26, isolated Coordinator worktree): initially
+off, enabled and persisted across reload, disabled back to classic navigation,
+then enabled back to Chat / Tasks / Needs You. This used `local_trusted`; signed-in
+two-person browser isolation remains unverified.
+
+Coordinator More exposes a pin/unpin button beside every destination. Each flyout
+row highlights as one surface; its pin appears on row hover or keyboard focus.
+Opening the flyout focuses its container so Search is not highlighted before
+interaction. Pinned pages appear beneath More in pinning order and retain the
+existing company-aware routes.
+Unpin from either the flyout or the pinned row. The list is personal to the current
+user in this browser, shared across companies; it does not sync across devices.
+Only known route names are rendered. Storage failures show a save error.
+The [pin hook](../../ui/src/hooks/usePinnedNavigation.ts) owns browser persistence;
+[sidebar tests](../../ui/src/components/CoordinatorSidebar.test.tsx) cover pin/unpin,
+remount persistence, account separation, unknown routes and cross-tab updates.
+Manual: pin with mouse and keyboard, reload, follow a pinned link, unpin from both
+locations, and check the mobile drawer. Local-trusted checks do not prove two-user
+authenticated browser isolation.

maps/feature-map/onboarding.md

@@ -56,6 +56,11 @@ checks the same held state, then completes that record through Connect without
 creating a second agent. Its Docker harness mocks credential verification; live
 provider authentication remains separate evidence.
 
+Name-only setup defers the runner field while the provisional adapter remains
+held in setup. Choosing a provider updates that same setup record with its
+selected runner. The wizard regression covers a saved native choice followed by
+OpenAI Subscription selection; it does not prove provider authentication.
+
 - **Create company and resume.** Start a fresh empty instance and run doctor using
   the [verification skill](../../.agents/skills/verify-paperclip/SKILL.md). Run
   `node .agents/skills/verify-paperclip/scripts/onboarding-smoke.mjs --evidence-dir "$VERIFY_EVIDENCE_DIR"`.

maps/feature-map/questions-and-approvals.md

@@ -216,6 +216,8 @@ unless its actual provider journey was driven.
 
 ## Gotchas
 
+- Canonical question forms show field validation only after Next/Submit (including the keyboard submit shortcut) is attempted. Invalid answers remain unsent and the form stays on the relevant question; correction clears the field warning. Pagination arrows still browse without validation, drafts remain preserved, and uploads/requests in flight still disable submission.
+
 - Dismissing a question does not answer it. Dismissing an app review neither
   grants permission nor resumes the agent. Ordinary comments cannot approve it.
 - A resolved request and a successful tool execution are separate facts.