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