@company-semantics/contracts 86.0.0 → 87.0.0

package/src/chat/README.md

@@ -29,7 +29,6 @@ Shared types for chat persistence, sharing, real-time events, and runtime profil
 - Chat mention offsets are ZERO-BASED UTF-16 CODE UNITS into the exact `content` string with `endOffset` EXCLUSIVE, and no Unicode normalization happens anywhere on the path — the same convention as `CommentMention`, because a mention means the same thing on both surfaces. An astral character counts as TWO units
 - Chat mention offsets are NULLABLE and null means "mentioned somewhere in this turn, highlight nothing", never an error. A user turn carries a real range; an assistant turn's mention is a typed part with no character range, and the nullability is what lets that land with no second schema
 - Identity on a chat mention renders from the mention ROW, never from the content characters under the range. A stale range can only mis-highlight; it can never misattribute
-- `SharedChatMessage` deliberately has NO mentions. The token-only share viewer is granted the CONTENT of a shared chat and nothing else; a mention row is identity, and identity is not in that grant
 - `ChatMentionableResponse` carries `MentionableCandidate` items imported from `comments`, not a chat-flavored copy. A candidate is a principal, a display name and an avatar on both surfaces — and on both, deliberately no email and no access level, because a picker that returned the band each candidate holds would be a way to enumerate who can do what
 - A chat message REQUIRES an `author`, and it is a `PrincipalRef` — so an assistant turn is the AGENT (`{ kind: "agent" }`), not a null and not a synthetic user id. `role` was sufficient while every chat had one human in it; with two participants `role: "user"` names a set, and a client with no author field can only render every human turn as the reader. That is silent misattribution, which is why this shipped in a MAJOR rather than as an optional field with a fallback (ADR-CONTRACTS-164)
 - `author` is a ref, never a display name. Identity renders through a read-time lookup — the same rule as a mention row's `displayName` — so a rename re-renders the whole transcript with no backfill
@@ -37,7 +36,8 @@ Shared types for chat persistence, sharing, real-time events, and runtime profil
 - `myRole` is per-READER, not a property of the chat: the same chat is `owner` to one person and `participant` to another over the same row shape. It is a hint for drawing; the server re-decides every owner-only action on its own
 - The summary carries a participant COUNT, never the roster. A 50-row sidebar page must not carry 50 rosters, and a chat's membership is not disclosed by the chat merely appearing in a list. `ChatDetail.participants` is where the names are, and it is optional — a missing roster is simply not drawn, whereas a guessed role is drawn wrong
 - A `ChatParticipant` is a USER, never a `PrincipalRef` — the deliberate asymmetry with a mention TARGET, which is a ref precisely so the agent can be named. The agent takes part in every chat by construction and has no participant row: it is mentionable, not a member, and cannot be added, removed or left
-- `ChatParticipantRole` has EXACTLY two members. A third would be an access band, and this is participation rather than an ACL: a participant sees the whole conversation, `owner` names the one person who additionally deletes, renames, pins and shares it, and a chat you can read half of is not a thing this surface models
+- `ChatParticipantRole` is `owner` / `participant` (Collaborate) / `viewer` (Read only), and SHARING A CHAT IS ADDING A PARTICIPANT at one of the two grantable roles (`ChatGrantableRole`). Access is whole-chat or nothing — a viewer reads the same live conversation a participant does and writes nothing; there is no token, no snapshot and no public link (ADR-CONTRACTS-206)
+- `ChatDetail.myRole` is REQUIRED, like the summary's: a chat opened from a link is on no loaded list page, and a guessed role draws a composer for a Read only viewer
 - The chat schemas are THREE files with a one-way load order: `enums.ts` (the closed vocabularies plus the `proactiveChatFields` / `multiPartyChatFields` groups) imports nothing from the domain, `event-schemas.ts` imports only from it, and `schemas.ts` imports from both and RE-EXPORTS them so `index.ts`, `types.ts` and the tests keep one import site. An import from either of the first two back into `schemas.ts` is a load cycle: the re-export edge is evaluated before `schemas.ts`'s body, so the shared declarations are reached in the temporal dead zone and every consumer throws a `ReferenceError` at import time. `continuity.ts` sits outside that set on the same terms: `schemas.ts` imports it, it never imports `schemas.ts`, and `index.ts` re-exports it directly (its types are declared beside its schemas, as `runtime-profile.ts` does)
 - `CHAT_PAGE_VIEWS` and `CHAT_PAGE_SCOPES` are a projection of the app's `Route` union (`company-semantics-app/src/platform/route-parser.ts`), not a parallel vocabulary. A view the parser can emit but the schema rejects fails the send outright rather than degrading
 
@@ -59,13 +59,14 @@ A chat can belong to a SUBJECT — the durable case a hand-off to chat is about
 
 ## Public API
 
+- `AddChatParticipantRequest` _(type)_ — Request for POST /api/chats/:chatId/participants — sharing the chat with one org member at a grantable role.
 - `BaseEvent` _(type)_ — Base envelope for all SSE events.
 - `BaseEventSchema`
 - `CHAT_CONTINUATION_REASONS` — Why a generation continues its predecessor.
 - `CHAT_DISCUSSION_REQUEST_TYPES` — The kinds of durable input request a turn can be scoped to.
 - `CHAT_PAGE_ENTITY_TYPES` — What kind of thing the reader has open, when they have one open.
 - `CHAT_PAGE_SCOPES` — The route parser's four URL scopes: unscoped, `/me/*`, `/team/*`, `/@:org/*`.
-- `CHAT_PAGE_VIEWS` — The app route parser's sixteen `type` values, projected onto the wire.
+- `CHAT_PAGE_VIEWS` — The app route parser's fifteen `type` values, projected onto the wire.
 - `CHAT_RUNTIME_PROFILES` — Ordered list of available profiles for UI rendering.
 - `CONVERSATION_SUBJECT_KINDS` — The kinds of subject a chat can continue.
 - `ChatByInteractionResponse` _(type)_ — Response for GET /api/chats/by-interaction/:interactionId
@@ -86,6 +87,8 @@ A chat can belong to a SUBJECT — the durable case a hand-off to chat is about
 - `ChatDiscussionScopeSchema` — WHAT THIS TURN IS ABOUT: one question of one input request, by stable id.
 - `ChatDomainEvent` _(type)_ — All domain events that carry full state.
 - `ChatDomainEventSchema`
+- `ChatGrantableRole` _(type)_ — A role a share can grant: `participant` (Collaborate) or `viewer` (Read only).
+- `ChatGrantableRoleSchema` — The roles a share can grant: Collaborate (`participant`) or Read only (`viewer`).
 - `ChatInvalidationEvent` _(type)_ — All invalidation events that signal staleness.
 - `ChatInvalidationEventSchema`
 - `ChatListFilters` _(type)_ — Filters for listing chats.
@@ -102,15 +105,13 @@ A chat can belong to a SUBJECT — the durable case a hand-off to chat is about
 - `ChatPageContext` _(type)_ — Where the reader is, as identifiers — route, view, scope and an optional `{ type, id }` entity.
 - `ChatPageContextSchema` — Where the reader is, as identifiers.
 - `ChatParticipant` _(type)_ — One ACTIVE participant of a chat — a user id, a role, a read-time display name and when they joined.
-- `ChatParticipantRole` _(type)_ — What one person is to a chat: `owner` or `participant`.
+- `ChatParticipantRole` _(type)_ — What one person is to a chat: `owner`, `participant` (Collaborate) or `viewer` (Read only).
 - `ChatParticipantRoleSchema` — What one person is to a chat.
 - `ChatParticipantSchema` — One active participant of a chat.
 - `ChatParticipantsResponse` _(type)_ — Response for GET /api/chats/:chatId/participants.
 - `ChatParticipantsResponseSchema` — Response for GET /api/chats/:chatId/participants.
 - `ChatRuntimeProfile` _(type)_ — Chat runtime profile — user-selectable orchestration strategy.
 - `ChatRuntimeProfileInfo` _(type)_ — Runtime profile metadata for UI rendering.
-- `ChatShareInfo` _(type)_ — Chat share record with snapshot metadata.
-- `ChatShareInfoSchema` — A chat share, as returned by the share APIs.
 - `ChatSseEvent` _(type)_ — SSE event types for chat updates.
 - `ChatSseEventSchema`
 - `ChatSuccessResponse` _(type)_ — Generic mutation success confirmation.
@@ -121,15 +122,10 @@ A chat can belong to a SUBJECT — the durable case a hand-off to chat is about
 - `ChatSummarySchema`
 - `ChatUpdatedEvent` _(type)_ — Emitted when chat metadata changes (title, pin, etc.) Carries full current state - clients should replace…
 - `ChatUpdatedEventSchema`
-- `ChatVisibility` _(type)_ — Chat share visibility. - private: Token exists but access requires authentication as chat owner - public…
-- `ChatVisibilitySchema`
 - `ConversationSubjectKind` _(type)_
 - `ConversationSubjectKindSchema`
 - `CreateChatResponse` _(type)_ — Response for POST /api/chats
 - `CreateChatResponseSchema` — Response for POST /api/chats
-- `CreateShareRequest` _(type)_ — Request to create a new share for a chat.
-- `CreateShareResponse` _(type)_ — Response for POST /api/chats/:chatId/shares
-- `CreateShareResponseSchema` — Response for POST /api/chats/:chatId/shares
 - `DEFAULT_CHAT_RUNTIME_PROFILE` — Default profile when none is specified in the request.
 - `GetChatResponse` _(type)_ — Response for GET /api/chats/:id
 - `GetChatResponseSchema` — Response for GET /api/chats/:id
@@ -145,17 +141,11 @@ A chat can belong to a SUBJECT — the durable case a hand-off to chat is about
 - `LaunchDispositionSchema`
 - `LaunchTargetSuperseded` _(type)_
 - `LaunchTargetSupersededSchema` — The 409 body the authoritative launch write returns when the posted chat is not — or can no longer become —…
-- `ListSharesResponse` _(type)_ — Response for GET /api/chats/:chatId/shares
-- `ListSharesResponseSchema` — Response for GET /api/chats/:chatId/shares
 - `ProactiveChatResolution` _(type)_ — Resolving an occurrence id to the CURRENT reader's chat — one of the four bounded states `ready` (with…
 - `ProactiveChatResolutionSchema` — Resolving an occurrence id to THIS reader's chat (INV-PROACTIVE-LINK).
 - `RecognizedProactiveKind` _(type)_ — A wire `proactiveKind` after recognition: a kind this contracts version knows, or the raw string it did not —…
 - `ResolveLaunchResponse` _(type)_
 - `ResolveLaunchResponseSchema` — Response of the read-only launch resolution.
-- `SharedChatMessage` _(type)_ — Individual message in a shared chat view.
-- `SharedChatMessageSchema`
-- `SharedChatView` _(type)_ — Shared chat view returned to viewers.
-- `SharedChatViewSchema`
 - `StartFreshChatResponse` _(type)_
 - `StartFreshChatResponseSchema` — Response of the start-fresh write: the NEW active generation of the subject, linked back to the chat it…
 - `TitleGenerationRequest` _(type)_ — Request to generate a title for a chat.
@@ -163,9 +153,7 @@ A chat can belong to a SUBJECT — the durable case a hand-off to chat is about
 - `TitleGenerationResponseSchema`
 - `TitleSource` _(type)_ — Title source - tracks how the title was set. - auto: Generated automatically by LLM - manual: Set by user…
 - `TitleSourceSchema`
-- `UpdateShareRequest` _(type)_ — Request to update an existing share.
-- `UpdateShareResponse` _(type)_ — Response for PATCH /api/shares/:shareId
-- `UpdateShareResponseSchema` — Response for PATCH /api/shares/:shareId
+- `UpdateChatParticipantRequest` _(type)_ — Request for PATCH /api/chats/:chatId/participants/:userId — the owner moving someone between Read only and…
 - `recognizeProactiveKind` — Recognize a wire `proactiveKind`.
 
 <!-- END GENERATED: readme-public-api -->

package/src/chat/__tests__/compaction-boundary.test.ts

@@ -32,6 +32,7 @@ const BASE_DETAIL = {
   id: "chat_1",
   title: "A long conversation",
   interactionId: "int_1",
+  myRole: "owner",
   createdAt: "2026-08-31T00:00:00.000Z",
   updatedAt: "2026-08-31T01:00:00.000Z",
   continuity: null,

package/src/chat/__tests__/continuity.test.ts

@@ -67,6 +67,7 @@ const BASE_DETAIL = {
   id: "chat_1",
   title: "Candidate review",
   interactionId: "int_1",
+  myRole: "owner",
   createdAt: "2026-09-01T00:00:00.000Z",
   updatedAt: "2026-09-01T01:00:00.000Z",
 };

package/src/chat/__tests__/discussion-scope.test.ts

@@ -11,7 +11,6 @@ import {
   CHAT_DISCUSSION_REQUEST_TYPES,
   ChatDiscussionScopeSchema,
   ChatMessageSchema,
-  SharedChatMessageSchema,
 } from "../schemas";
 
 const VALID = {
@@ -90,12 +89,6 @@ describe("where a scope may be SEEN", () => {
     expect("discussionScope" in ChatMessageSchema.shape).toBe(true);
   });
 
-  it("is ABSENT from the shared-chat message, which is a separate type", () => {
-    // A token-only share reader sees the turn without its anchor line, and the
-    // question is named nowhere. This asymmetry is the design, not an oversight.
-    expect("discussionScope" in SharedChatMessageSchema.shape).toBe(false);
-  });
-
   it("is optional, so a turn about nothing in particular simply omits it", () => {
     const parsed = ChatMessageSchema.shape.discussionScope.safeParse(undefined);
     expect(parsed.success).toBe(true);

package/src/chat/__tests__/message-mentions.test.ts

@@ -18,9 +18,6 @@
  *   exclusive. An astral character counts as TWO. Asserted against a real slice
  *   rather than stated, because a client measuring code POINTS produces ranges
  *   that look right until an emoji precedes the mention.
- * - `SharedChatMessageSchema` did NOT gain mentions. The token-only share viewer
- *   renders content, not identity chips, and a mention row is identity a
- *   tokenholder was never granted.
  * - `ChatMentionableResponseSchema` carries `MentionableCandidateSchema` items —
  *   the comments shape imported, not a chat-flavored copy of it.
  */
@@ -31,7 +28,6 @@ import {
   ChatMessageMentionSchema,
   ChatMessageSchema,
   GetChatResponseSchema,
-  SharedChatMessageSchema,
 } from "../schemas.js";
 
 // ---------------------------------------------------------------------------
@@ -93,6 +89,7 @@ describe("ChatMessageSchema mentions", () => {
         id: "chat_1",
         title: "A conversation",
         interactionId: "int_1",
+        myRole: "owner",
         createdAt: "2026-09-02T00:00:00.000Z",
         updatedAt: "2026-09-02T01:00:00.000Z",
         continuity: null,
@@ -102,14 +99,6 @@ describe("ChatMessageSchema mentions", () => {
 
     expect(parsed.messages[0].mentions).toHaveLength(1);
   });
-
-  it("the share viewer's message shape did not gain mentions", () => {
-    // A token holder is granted the CONTENT of a shared chat and nothing else.
-    // Mention rows are identity, and identity is not in the grant.
-    expect(Object.keys(SharedChatMessageSchema.shape)).not.toContain(
-      "mentions",
-    );
-  });
 });
 
 describe("ChatMessageMentionSchema", () => {

package/src/chat/__tests__/multi-party.test.ts

@@ -31,6 +31,7 @@ import {
   ChatDetailSchema,
   ChatMessageSchema,
   ChatParticipantRoleSchema,
+  ChatGrantableRoleSchema,
   ChatParticipantSchema,
   ChatParticipantsResponseSchema,
   ChatSummaryExtendedSchema,
@@ -122,6 +123,7 @@ const BASE_DETAIL = {
   id: "chat_1",
   title: "Q3 planning",
   interactionId: "int_1",
+  myRole: "owner",
   createdAt: ISO,
   updatedAt: ISO,
   continuity: null,
@@ -176,14 +178,21 @@ describe("ChatMessageSchema author", () => {
 });
 
 describe("the participant role vocabulary", () => {
-  it("has exactly two members — participation, not an access band", () => {
-    // A third role would be a band ladder, and a band ladder is the ACL entity
-    // this decision declined. A participant sees the whole conversation.
-    expect(ChatParticipantRoleSchema.options).toEqual(["owner", "participant"]);
+  it("is owner, participant (Collaborate) and viewer (Read only) — ADR-CONTRACTS-206", () => {
+    expect(ChatParticipantRoleSchema.options).toEqual([
+      "owner",
+      "participant",
+      "viewer",
+    ]);
   });
 
-  it("rejects a band that reads like an access level", () => {
-    for (const role of ["viewer", "commenter", "editor", "admin"]) {
+  it("grants only Collaborate or Read only — owner is never granted", () => {
+    expect(ChatGrantableRoleSchema.options).toEqual(["participant", "viewer"]);
+    expect(ChatGrantableRoleSchema.safeParse("owner").success).toBe(false);
+  });
+
+  it("rejects a band that is not whole-chat access", () => {
+    for (const role of ["commenter", "editor", "admin"]) {
       expect(ChatParticipantRoleSchema.safeParse(role).success, role).toBe(
         false,
       );

package/src/chat/__tests__/page-context.test.ts

@@ -211,9 +211,9 @@ describe("ChatPageContext is the ceiling on both axes", () => {
     expect(ChatPageContextSchema.safeParse(VALID).success).toBe(true);
     expect(
       ChatPageContextSchema.safeParse({
-        route: "/chat/abc",
-        view: "chat",
-        scope: "none",
+        route: "/me/work",
+        view: "work",
+        scope: "me",
         entity: { type: "chat", id: "abc" },
       }).success,
     ).toBe(true);

package/src/chat/enums.ts

@@ -20,7 +20,6 @@
 
 import { z } from "zod";
 
-export const ChatVisibilitySchema = z.enum(["private", "public"]);
 export const TitleSourceSchema = z.enum(["auto", "manual"]);
 export const InvalidationReasonSchema = z.enum([
   "external-mutation",
@@ -44,18 +43,32 @@ export const ChatOriginSchema = z.enum(["user", "proactive"]);
 /**
  * What one person is to a chat.
  *
- * TWO ROLES AND NO BAND LADDER. This is participation, not an access-control
- * list: a participant sees the whole conversation and may add someone else,
- * and `owner` names the one person who additionally deletes, renames, pins and
- * shares it. There is deliberately no `viewer`, no `commenter` and no
- * per-participant scope — a chat you can read half of is not a thing this
- * surface models, and a third role is what an ACL entity would have given us
- * along with the grant compiler this decision declines.
+ * Participation with ONE access distinction, whole-chat or nothing:
+ * - `participant` (Collaborate) sees the whole live conversation, takes turns
+ *   under the turn lock and may share the chat onward;
+ * - `viewer` (Read only) sees the same whole live conversation and writes
+ *   nothing — no turn, no share, no retitle;
+ * - `owner` is the one participant who additionally deletes, renames, pins and
+ *   changes another person's access.
+ *
+ * Sharing a chat IS adding a participant row with one of the two grantable
+ * roles (ADR-CONTRACTS-206). There is still no per-participant scope — a chat
+ * you can read half of is not a thing this surface models.
  *
  * EXACTLY ONE OWNER, and it never changes hands: ownership transfer is out of
  * scope, and the owner cannot leave their own chat.
  */
-export const ChatParticipantRoleSchema = z.enum(["owner", "participant"]);
+export const ChatParticipantRoleSchema = z.enum([
+  "owner",
+  "participant",
+  "viewer",
+]);
+
+/**
+ * The roles a share can grant: Collaborate (`participant`) or Read only
+ * (`viewer`). `owner` is never granted — it is the chat's creator, once.
+ */
+export const ChatGrantableRoleSchema = z.enum(["participant", "viewer"]);
 
 /**
  * The three proactive wire fields, stated ONCE and spread into every shape
@@ -134,8 +147,8 @@ export const multiPartyChatFields = {
    * the same chat is `owner` to one person and `participant` to another, and
    * the same row shape reaches both.
    *
-   * The client gates the owner-only affordances (delete, rename, pin, share) on
-   * this. It is a hint for drawing, not the enforcement — the server re-decides
+   * The client gates the owner-only affordances (delete, rename, pin, access
+   * changes) and the read-only composer on this. It is a hint for drawing, not the enforcement — the server re-decides
    * every one of them on its own.
    */
   myRole: ChatParticipantRoleSchema,

package/src/chat/index.ts

@@ -10,13 +10,7 @@
 // =============================================================================
 
 export type {
-  ChatVisibility,
   ChatSummary,
-  ChatShareInfo,
-  SharedChatView,
-  SharedChatMessage,
-  CreateShareRequest,
-  UpdateShareRequest,
   // Chat lifecycle types
   TitleSource,
   ChatListFilters,
@@ -46,9 +40,6 @@ export type {
   ChatByInteractionResponse,
   ChatListResponse,
   CreateChatResponse,
-  CreateShareResponse,
-  ListSharesResponse,
-  UpdateShareResponse,
   ChatMessage,
   // Mentions on a chat turn (ADR-CONTRACTS-160): a PrincipalRef target, so the
   // agent is a legal mention target on the chat surface too.
@@ -57,6 +48,9 @@ export type {
   // Participants (ADR-CONTRACTS-164): a chat is a room with a membership, not
   // an ACL entity. The agent is mentionable but never a member.
   ChatParticipantRole,
+  ChatGrantableRole,
+  AddChatParticipantRequest,
+  UpdateChatParticipantRequest,
   ChatParticipant,
   ChatParticipantsResponse,
   ChatDetail,
@@ -71,7 +65,6 @@ export type {
 // =============================================================================
 
 export {
-  ChatVisibilitySchema,
   TitleSourceSchema,
   InvalidationReasonSchema,
   ChatChangedFieldSchema,
@@ -80,9 +73,6 @@ export {
   ChatSummaryExtendedSchema,
   ProactiveChatResolutionSchema,
   TitleGenerationResponseSchema,
-  SharedChatMessageSchema,
-  ChatShareInfoSchema,
-  SharedChatViewSchema,
   BaseEventSchema,
   ChatCreatedEventSchema,
   ChatUpdatedEventSchema,
@@ -97,15 +87,13 @@ export {
   ChatByInteractionResponseSchema,
   ChatListResponseSchema,
   CreateChatResponseSchema,
-  CreateShareResponseSchema,
-  ListSharesResponseSchema,
-  UpdateShareResponseSchema,
   ChatMessageSchema,
   ChatMessageMentionSchema,
   ChatMentionableResponseSchema,
   // Participants: the role vocabulary, one participant row, and the list
   // envelope for GET /api/chats/:chatId/participants.
   ChatParticipantRoleSchema,
+  ChatGrantableRoleSchema,
   ChatParticipantSchema,
   ChatParticipantsResponseSchema,
   ChatDetailSchema,

package/src/chat/schemas.ts

@@ -21,7 +21,6 @@ import { PrincipalRefSchema } from "../identity/agent";
 import { ChatContinuitySchema } from "./continuity";
 import {
   ChatParticipantRoleSchema,
-  ChatVisibilitySchema,
   multiPartyChatFields,
   proactiveChatFields,
   TitleSourceSchema,
@@ -30,12 +29,12 @@ import {
 // The chat vocabulary and the SSE event contract, re-exported so this module
 // stays the single import site for every chat schema.
 export {
-  ChatVisibilitySchema,
   TitleSourceSchema,
   InvalidationReasonSchema,
   ChatChangedFieldSchema,
   ChatOriginSchema,
   ChatParticipantRoleSchema,
+  ChatGrantableRoleSchema,
 } from "./enums";
 
 export {
@@ -111,53 +110,6 @@ export const TitleGenerationResponseSchema = z.object({
   isAutoGenerated: z.boolean(),
 });
 
-// =============================================================================
-// Share Types
-// =============================================================================
-
-export const SharedChatMessageSchema = z.object({
-  role: z.enum(["user", "assistant"]),
-  content: z.string(),
-  parts: z.array(z.unknown()).optional(),
-});
-
-/**
- * A chat share, as returned by the share APIs.
- *
- * SHOW-ONCE (ADR-BE-460). `token` and `shareUrl` are present ONLY on the
- * response that creates the share. Share tokens are stored as a digest, so the
- * server cannot redisplay one afterwards — listing or updating a share returns
- * the record without them, and re-obtaining a link means revoke-and-reshare.
- *
- * This is the industry norm for capability links, and it is what removes the
- * last reason to keep a recoverable copy of the token: a share list that can
- * still show you the URL is a share list that can leak every live link at once.
- * Consumers must treat both fields as optional and drive their copy-link
- * affordance off creation, not off a fetched share.
- */
-export const ChatShareInfoSchema = z.object({
-  id: z.string(),
-  chatId: z.string(),
-  /** Create-time only — never returned by list or update (show-once). */
-  token: z.string().optional(),
-  visibility: ChatVisibilitySchema,
-  /** Create-time only — never returned by list or update (show-once). */
-  shareUrl: z.string().optional(),
-  messageCountAtShare: z.number().int(),
-  titleAtShare: z.string(),
-  createdAt: IsoDateTime,
-  createdByName: z.string(),
-  isRevoked: z.boolean(),
-});
-
-export const SharedChatViewSchema = z.object({
-  title: z.string(),
-  messages: z.array(SharedChatMessageSchema),
-  sharedAt: IsoDateTime,
-  sharedByName: z.string(),
-  visibility: ChatVisibilitySchema,
-});
-
 // =============================================================================
 // Message Types
 // =============================================================================
@@ -331,10 +283,6 @@ export const ChatMessageSchema = z.object({
    * not know this field renders the transcript exactly as it did before — the
    * same reasoning as `compactedThroughSequence`.
    *
-   * ON THE AUTHENTICATED TRANSCRIPT ONLY. `SharedChatMessageSchema` is a
-   * separate type and does not carry it, so a scoped turn shown to a token-only
-   * share reader has no anchor line and names no question. That asymmetry is
-   * the point, not an oversight.
    */
   discussionScope: ChatDiscussionScopeSchema.optional(),
 });
@@ -398,22 +346,6 @@ export const CreateChatResponseSchema = z.object({
   chat: ChatSummaryExtendedSchema,
 });
 
-/** Response for POST /api/chats/:chatId/shares */
-export const CreateShareResponseSchema = z.object({
-  share: ChatShareInfoSchema,
-  shareUrl: z.string(),
-});
-
-/** Response for GET /api/chats/:chatId/shares */
-export const ListSharesResponseSchema = z.object({
-  shares: z.array(ChatShareInfoSchema),
-});
-
-/** Response for PATCH /api/shares/:shareId */
-export const UpdateShareResponseSchema = z.object({
-  share: ChatShareInfoSchema,
-});
-
 /**
  * Chat detail object in GET /api/chats/:id response.
  * Extends the base summary with interactionId (needed for append-on-edit flows).
@@ -469,6 +401,13 @@ export const ChatDetailSchema = z.object({
    * an empty array is not a state the server produces.
    */
   participants: z.array(ChatParticipantSchema).optional(),
+  /**
+   * What the READER is to this chat — the same per-reader fact the summary
+   * carries as `myRole`, on the detail too so a chat opened from a link (and
+   * so on no loaded list page) still knows whether to draw a composer.
+   * REQUIRED: guessing it draws a composer for a Read only viewer.
+   */
+  myRole: ChatParticipantRoleSchema,
   /**
    * The chat's place in its subject's lineage (chat-continuity-wire-vocabulary).
    * NULL for a chat that belongs to no subject. REQUIRED, not optional: a
@@ -509,7 +448,7 @@ export const ChatMentionableResponseSchema = z.object({
 // =============================================================================
 
 /**
- * The app route parser's sixteen `type` values, projected onto the wire.
+ * The app route parser's fifteen `type` values, projected onto the wire.
  *
  * A PROJECTION, not a parallel vocabulary: keep it in step with
  * `company-semantics-app/src/platform/route-parser.ts`. A view the parser can
@@ -518,7 +457,6 @@ export const ChatMentionableResponseSchema = z.object({
  * reads that parser's source and compares the two.
  */
 export const CHAT_PAGE_VIEWS = [
-  "chat",
   "company-md",
   "execution-detail",
   "internal-admin",