@pitcher/js-api 1.30.0 → 1.31.0

package/lib/components/masterCanvases/createFromMaster.use.d.ts

@@ -0,0 +1,255 @@
+import { CanvasCreateRequest, CanvasRetrieve } from '../../../types/openapi';
+/**
+ * Metadata for a MASTER created from an existing canvas ("Use as master").
+ *
+ * Strips the source deck's own bookkeeping — the async-download record, so the new master does not
+ * offer a download of the SOURCE rendered before it became a master, and `frozen_until`, so a
+ * brand-new master is not born read-only.
+ *
+ * Deliberately KEEPS `pitcher.completion_wizard`, which is what separates this from
+ * `buildChildMetadata`. A master is a finished source: block 3 lets the wizard state survive into
+ * `context` (`buildMasterContext` prunes identity only), so pruning the `metadata` twin here would
+ * desynchronise the two and make the list's Progress column disagree with the wizard itself.
+ * Reusing `buildChildMetadata` would have been the intuitive fix and the wrong one.
+ */
+export declare function buildMasterMetadata(sourceMetadata?: CanvasRetrieve['metadata'] | null): Record<string, unknown> | undefined;
+/**
+ * The create payload for "Use as master pitchdeck" (PIT-7488 block 3).
+ *
+ * Mirror image of `buildCreateFromMasterPayload`, and it lives beside it for the same reason
+ * `buildMasterMetadata` does: the two directions must be read together or they drift.
+ *
+ * **`owned_by_id` is absent, and that absence is the contract (PIT-8362).** Django declares the
+ * field `default=CreateOnlyDefault(CurrentUserDefault())`, so omitting it is precisely what makes
+ * the master belong to whoever promoted the deck — the only owner "My Master Pitchdecks" can
+ * meaningfully show, since it is a personal, RESTRICTED, owner-scoped tab that the promote flow
+ * navigates to on success. Sending the SOURCE deck's owner instead (block 3's original rule,
+ * reverted here) put a colleague's master in the promoter's tab, and `CanvasOwnedByFieldValidator`
+ * 400s that transfer outright for anyone but an org/instance admin. Do not reintroduce the field.
+ *
+ * The rest mirrors the source deck, minus what a master must not inherit:
+ * - `account: null` + `access_type: RESTRICTED` — masters are account-less internal sources rather
+ *   than shared content (`resolve_account` nulls the account server-side anyway).
+ * - `context` — identity is stripped so every deck built from this master renders the PRESENTING
+ *   rep in `{{user.name}}`, not the promoter. See `buildMasterContext`.
+ * - `metadata` — drops the source's async-download record (its Actions cell would otherwise offer a
+ *   completed download of the deck as it was BEFORE becoming a master) and `pitcher.frozen_until`
+ *   (a brand-new master born read-only). Deliberately NOT `buildChildMetadata`: that also drops the
+ *   completion wizard, which a master keeps, and `buildMasterContext` keeps its `context` twin —
+ *   the two must agree.
+ *
+ * - `is_draft: false` — forced, NOT inherited (PIT-8360). Masters have no draft state since the
+ *   Ready column was dropped from the master tab (validation item #44), so nothing can clear the
+ *   flag afterwards: a deck promoted while still a draft would produce a permanently-draft master.
+ *   This keeps the promote path agreeing with the other three master-creation paths in
+ *   `MasterCanvasesView`, which force it too, rather than leaving `is_draft` set on masters with
+ *   nothing that sets it FOR them, waiting to bite whoever next writes a filter against it.
+ */
+export declare function buildMasterFromCanvasPayload(opts: {
+    source: CanvasRetrieve;
+    name: string;
+}): Omit<CanvasCreateRequest, 'instance_id'>;
+/**
+ * Drops the SOURCE's completion-wizard progress from a context that is otherwise copied verbatim.
+ *
+ * For the plain Duplicate action, which — unlike create-from-master — legitimately keeps the
+ * source's identity: the copy belongs to the same person, for the same account, so stripping
+ * `user`/`account` there would blank a deck the rep expects to be a faithful duplicate. The wizard
+ * state is different: `isCompletionWizardShowing` is `wizardSteps.length > 0 &&
+ * !context.pitcher.completion_wizard.completed`, so inheriting `completed: true` makes the copy
+ * open straight into the editor with the wizard silently skipped.
+ *
+ * Returns `undefined` when nothing survives, so the payload omits the field rather than writing an
+ * empty object over the server's default.
+ */
+export declare function withoutWizardState(context?: CanvasRetrieve['context'] | null): Record<string, unknown> | undefined;
+/**
+ * Context for a DUPLICATE (PIT-7488, peer review round 2).
+ *
+ * A pitchdeck copy strips the wizard state outright — see `withoutWizardState`. A MASTER copy cannot
+ * do either extreme:
+ *
+ * - Stripping it outright makes the copy look un-run, so the wizard reopens as a fresh `create`
+ *   seeded from the ADMIN GROUP CONFIG and completing it writes that seed over the curated slides
+ *   the rep just duplicated.
+ * - Keeping it verbatim inherits `completed: true`, which is the switch `isCompletionWizardShowing`
+ *   reads — the copy then opens straight into the editor and never offers the wizard at all, while
+ *   its Progress chip (from `metadata`) still says In progress. That desync is the whole reason
+ *   `withoutWizardState` exists.
+ *
+ * So a master copy is re-marked as what it actually is: a deck that HAS been through the wizard but
+ * is not finished. `react_saved` is exactly that state — `resolveWizardFlow` reads it as `edit` (so
+ * the copy restores its OWN content), while `completed` stays falsy so the wizard still shows and
+ * the chip still reads In progress, agreeing with `buildChildMetadata`.
+ *
+ * The marker is added only when the source carries a RESTORABLE artifact — see
+ * `hasRestorableArtifact`, which is the sole gate on this path because the edit flow has no
+ * downstream `fromArtifact` check. A master with nothing to restore must not claim `react_saved`, or
+ * the edit flow restores from an artifact that is not there and reopens the empty-`edit` bug (Q9).
+ * `initial_section_list_data` is dropped either way, so the copy re-seeds its candidate baseline
+ * from its own content rather than re-offering slides the source deliberately dropped.
+ */
+export declare function buildDuplicateContext(context?: CanvasRetrieve['context'] | null, opts?: {
+    isMaster?: boolean;
+}): Record<string, unknown> | undefined;
+/**
+ * Freezing a master says "this source is locked", not "every deck built from it is locked" — and a
+ * brand new deck the rep cannot edit is unusable.
+ */
+export declare function buildChildMetadata(masterMetadata?: CanvasRetrieve['metadata'] | null): Record<string, unknown> | undefined;
+/**
+ * The child's context: the master's configuration plus this session's identity.
+ *
+ * Identity is **stripped and re-added** rather than merged over, and that is the load-bearing
+ * detail. `getDefaultCrmShape` runs its result through `removeEmptyValues`, so on a non-CRM org
+ * (or with no live call) it emits no `account` and no `meeting` at all — a plain merge would then
+ * leave whatever the master carried, which is the wrong customer's name on the new deck. Stripping
+ * first means the child's identity keys can only ever come from the current session.
+ *
+ * It cannot rely on block 3 having cleaned the master either: `buildMasterContext` runs once, at
+ * creation, and opening a master in the builder afterwards deep-merges live `Account` /
+ * `salesforce_data` / `pitcher_data` back into its context. Every master is therefore re-poisonable
+ * between creation and use, and this is the last gate before a customer sees the result.
+ *
+ * `accountName` overrides whatever the CRM shape resolved because `getDefaultCrmShape` prefers the
+ * LIVE call's selected account (`call.selectedAccount.Name ?? accountName`). The account chosen in
+ * the dialog is the deck's account, so a rep prepping a deck for Beta during a call with Acme must
+ * not get Acme's name interpolated into it.
+ *
+ * The wizard artifact's OWN identity goes too (`withoutWizardIdentity`): the top-level key list
+ * never reached `wizard.subtitle`, so the promoter's customer rode onto the child's cover slide via
+ * `{{wizard.subtitle.label}}` (PIT-8399). Masters are re-poisonable after creation, so this pass
+ * has to run here as well as in `buildMasterContext`.
+ *
+ * The master's wizard PROGRESS is replaced rather than merely dropped (`pitcher.completion_wizard`,
+ * see `WIZARD_STATE_PITCHER_KEY`). Dropping it is what lets the completion wizard run on the new
+ * deck — on a `enable_react_completion_wizard` instance, the `pitchdeck-wizard-ng` app — but a deck
+ * with NO wizard state at all also reads as never-curated, and the wizard's create flow then
+ * reseeds its agenda from the ADMIN GROUP CONFIG, silently dropping every custom agenda point the
+ * master carried (PIT-8399, the reported defect). So the progress is reset to the one fact that
+ * survives: `from_master`, which says "this deck's content was copied from a curated source, so its
+ * own artifact is the authoritative agenda". `resolveWizardAgendaSource` reads it.
+ *
+ * `from_master` deliberately sets NONE of `completed` / `edited` / `react_saved`, so
+ * `resolveWizardFlow` still answers `'create'`: the deck really is being created, the editor still
+ * says so, and identity stays with the create flow rather than being restored off the master. That
+ * is what separates this from `buildDuplicateContext`, which marks a master COPY `react_saved` and
+ * accepts the `'edit'` flow because a duplicate legitimately IS the source. Do not unify the two.
+ *
+ * **Knock-on the marker's PRESENCE has** (review): `App.vue` computes
+ * `hasWizardState: isCompletionWizardEnabled || !!context.pitcher.completion_wizard` as a
+ * deliberate proxy for the window before the app roster loads, so a from-master deck now satisfies
+ * it from creation onward where it previously had no such key. With
+ * `enable_edit_opens_completion_wizard` on, `isWizardOwnedEditSurface` therefore holds the surface
+ * for such a deck immediately — correct whenever the deck has wizard steps, which is every normal
+ * case, and the marker is only written when the master carried an artifact, which means the wizard
+ * had already run on it. The sharp edge is a deck with an artifact and ZERO steps (its SectionList
+ * node deleted in the raw builder after the wizard ran): it is demoted out of edit mode with no
+ * wizard to open. That edge PREDATES this change — every deck that has ever run the wizard carries
+ * the same key — and this only adds one more way to reach it, so it is accepted rather than worked
+ * around here. Do not "optimise" the marker away on the assumption it is inert.
+ *
+ * Written only when the copied context actually still CARRIES an artifact (`context.wizard`) — not
+ * when the master merely had wizard PROGRESS. Those two come apart in both directions and both are
+ * wrong: `ensureWizardInitialized` writes `pitcher.completion_wizard` when the wizard OPENS, so a
+ * master whose wizard was opened and cancelled has progress and no artifact (5 such masters live on
+ * test-eu), while a master with an artifact and no progress key would be left unfixed. Claiming an
+ * artifact that is not there reopens the empty-`edit` bug from the other side (PIT-7488 QA Q9): the
+ * restore finds no skeletons and parks every ref on one unnamed point.
+ *
+ * Returns `undefined` rather than `{}` so the create payload omits the field instead of writing an
+ * empty object over the server's default.
+ */
+export declare function buildContextFromMaster(opts: {
+    masterContext?: CanvasRetrieve['context'] | null;
+    /** `getDefaultCrmShape({ accountName, myUser })` — passed in because it needs Vue injection. */
+    crmShape?: Record<string, unknown> | null;
+    /** The account chosen in the dialog, already privacy-mode-adjusted (blank name = store no name). */
+    account?: {
+        id: string;
+        name?: string;
+    } | null;
+}): Record<string, unknown> | undefined;
+/**
+ * The create payload for a pitchdeck built from a master.
+ *
+ * `is_master: false` is spelled out rather than left to the spread: the fetched master carries
+ * `is_master: true`, and the flow also runs FROM the master tab, whose own `creator` exists to make
+ * masters. The child is an ordinary deck — it appears on the Pitchdecks tab, it has an account, and
+ * it is the thing the rep presents.
+ *
+ * `is_draft: false` matches the platform's other rep-facing creation flows (the create wizard posts
+ * `is_draft: false`). Inheriting the master's flag would silently mark customer-facing decks as
+ * drafts whenever the master was left in draft — a master's own status is bookkeeping for a source
+ * artifact and says nothing about the deck made from it.
+ *
+ * `access_type` is deliberately absent: it rides along from the master via the spread, and the host
+ * `creator` forces the value it wants (RESTRICTED for rep-created decks).
+ */
+export declare function buildCreateFromMasterPayload(opts: {
+    master: CanvasRetrieve;
+    name: string;
+    /** Already privacy-mode-adjusted by the caller (`enable_crm_privacy_mode` blanks the name). */
+    account?: {
+        id: string;
+        name?: string;
+    } | null;
+    crmShape?: Record<string, unknown> | null;
+}): Omit<CanvasCreateRequest, 'instance_id'>;
+/**
+ * Whether the dialog must collect an account before it can create.
+ *
+ * Follows the platform setting rather than the prototype's always-required Account field: on a
+ * non-CRM org there are no accounts to offer, so requiring one would make the whole feature
+ * unreachable. Same rule the create modal and the duplicate flow already apply.
+ */
+export declare function shouldRequireAccountOnCreateFromMaster(opts: {
+    isCRM?: boolean;
+    requireAccountOnCanvasCreation?: boolean;
+}): boolean;
+type MasterOption = Pick<CanvasRetrieve, 'id' | 'name'>;
+/**
+ * Guarantees the master a row action was fired from is in the offered list.
+ *
+ * Since PIT-8360 dropped the picker's `is_draft: false` fetch filter the two lists agree, so this is
+ * now a guard rather than the everyday path: it still covers a master created or renamed after the
+ * list was fetched, and the `fetchAll` truncation at `MAX_FETCH_LIMIT`. Without it the rep could
+ * click a master's "Use to create pitchdeck" and land in a picker that neither preselects nor offers
+ * it. Sibling of `buildMasterPickerOptions`, which applies the same rule to the Vue dialog's option
+ * shape.
+ */
+export declare function withPreselectedMaster<T extends {
+    id: string;
+}>(masters: T[], preselected?: T | null): T[];
+/**
+ * Options for the dialog's master picker.
+ *
+ * The picker lists every master since PIT-8360 dropped the fetch's `is_draft: false` filter — with
+ * the master tab's Ready column gone, nothing can clear the flag, so filtering would permanently
+ * hide masters already stored as drafts.
+ *
+ * **No draft marker on the labels** (PR review). It used to suffix "(Draft)", which was already
+ * unreachable — the fetch narrows to `id,name,tags,modified_at`, so every option arrived with
+ * `is_draft === undefined`. Restoring it via the `fields` list would have been the wrong repair:
+ * masters have no draft state to advertise any more, and a badge on a subset of them describes a
+ * distinction nothing in the product can act on. Dropping it also removes the hook a future reader
+ * would most likely rebuild a filter around.
+ *
+ * The preselected master is still injected — see `withPreselectedMaster` for the cases that still
+ * reaches.
+ */
+export declare function buildMasterPickerOptions(opts: {
+    masters: MasterOption[];
+    preselected?: MasterOption | null;
+}): {
+    label: string;
+    value: string;
+}[];
+/** Guards the submit button. A blank name would create a nameless row in the rep's own list. */
+export declare function canSubmitCreateFromMaster(opts: {
+    name?: string | null;
+    masterId?: string | null;
+    isAccountRequired?: boolean;
+    accountId?: string | null;
+}): boolean;
+export {};

package/lib/components/masterCanvases/createFromMaster.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/masterCanvasDocuments.use.d.ts

@@ -0,0 +1,56 @@
+/**
+ * PIT-7488 block 7 — pure logic behind the Documents column.
+ *
+ * Display only. The decision of WHICH masters to render lives server-side, in next-core's
+ * `selectCanvasIdsNeedingRender`: the bulk read already computes `is_stale` in SQL, so keeping the
+ * policy next to it avoids two copies of the same rule drifting apart in two languages.
+ *
+ * Kept free of Vue so the state machine is testable on its own.
+ */
+/**
+ * Mirrors next-core's `MasterDocumentsState`. Duplicated deliberately — next-core types are not
+ * published to canvas-ui, and canvas-ui must not import from next-core.
+ */
+export interface MasterDocumentsState {
+    status: 'pending' | 'rendering' | 'ready' | 'failed';
+    pdf_url: string | null;
+    pptx_url: string | null;
+    rendered_at: string | null;
+    is_stale: boolean;
+    attempts: number;
+    error: string | null;
+}
+export type DocumentsCellState = 
+/** No documents row at all — this master has never been rendered. */
+'none'
+/** A render is queued or running. */
+ | 'rendering'
+/** Current documents are available. */
+ | 'ready'
+/** Documents are available but out of date; a fresh render is coming. */
+ | 'ready_refreshing'
+/** The last render failed. */
+ | 'failed';
+/**
+ * Must match next-core's `MAX_RENDER_ATTEMPTS`. A client offering a fourth retry would render a
+ * button the server refuses to act on.
+ */
+export declare const MAX_RENDER_ATTEMPTS = 3;
+/**
+ * Maps a documents row onto what the cell should show.
+ *
+ * The `ready` + stale case deliberately keeps the existing links rather than reverting to a spinner:
+ * a slightly out-of-date document a rep can open beats a dead control. Only a genuinely absent
+ * artifact shows progress.
+ */
+export declare function resolveDocumentsCellState(state: MasterDocumentsState | undefined | null): DocumentsCellState;
+/**
+ * Whether to offer Retry. Only for a failed row, and only while the server would still act on it.
+ */
+export declare function canRetryDocuments(state: MasterDocumentsState | undefined | null): boolean;
+/**
+ * Whether the cell has anything openable. Drives the disabled state of each link independently —
+ * the two artifacts have different lifetimes (the PPTX object expires days before the PDF's URL
+ * mapping does), so one can be present while the other is not.
+ */
+export declare function hasOpenableDocument(state: MasterDocumentsState | undefined | null, format: 'pdf' | 'pptx'): boolean;

package/lib/components/masterCanvases/masterCanvasDocuments.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/masterCanvasShares.use.d.ts

@@ -0,0 +1,103 @@
+import { MiniUser } from '../../../types/openapi';
+/** Exactly `Collaboration['user']` and the "Sent to" cell's prop element (PIT-8421; was "Shared with"). */
+export type MasterCanvasShareUser = MiniUser;
+/**
+ * PIT-7488 block 5 — may the current user CHANGE this master canvas (Edit / Delete / Freeze)?
+ *
+ * The owner, **or an instance admin/editor**. That second arm mirrors Django's write gate
+ * exactly — `CanvasPermission.has_object_permission` returns True for
+ * `is_instance_admin or is_instance_editor or obj.is_owner(user)` — and it matters because the
+ * master list is not "only mine" for those roles: admins and editors route through
+ * `filter_by_admin_access`, so they see every master in the instance. Gating on ownership alone
+ * made the UI STRICTER than the API and silently removed Edit/Delete/Freeze from every master an
+ * admin did not personally own.
+ *
+ * A share recipient never reaches this gate on the SENDER's master: accepting an invitation mints
+ * a copy they own, so they meet the ownership arm on their own row and the sender's original is
+ * not in their list at all. That is why ng-rest-api#1688's read gates were reverted (#1689) —
+ * under invitation semantics there is no "viewing someone else's master" state to widen for.
+ *
+ * Fails closed, and deliberately not a bare `ownerId === myUserId`: that returns true when both
+ * are `undefined`, which would hand a recipient full control of any master whose owner failed to
+ * serialise.
+ */
+export declare function canManageMasterCanvas(opts: {
+    ownerId?: number | null;
+    myUserId?: number | null;
+    isAdminOrEditor?: boolean;
+}): boolean;
+/**
+ * PIT-7488 block 5 — may the current user SHARE this master canvas?
+ *
+ * The owner ONLY — deliberately narrower than `canManageMasterCanvas`. The next-core route is
+ * owner-gated (`master.ownedById !== user.id` → 403), so offering "Share with" to an admin on
+ * someone else's master would surface an action the API refuses. Sharing is the owner's call
+ * about their own material, not a moderation capability.
+ */
+export declare function canShareMasterCanvas(opts: {
+    ownerId?: number | null;
+    myUserId?: number | null;
+}): boolean;
+/**
+ * Per-user outcome of a send, mirroring next-core's `InvitationResult`.
+ *
+ * `already_invited` is benign (the UNIQUE key makes a repeat a no-op); `not_a_member` means the
+ * picker offered someone the server then refused, which the sender needs told.
+ */
+export type MasterShareInvitationStatus = 'invited' | 'already_invited' | 'not_a_member' | 'self';
+export interface MasterShareInvitationResult {
+    user_id: number;
+    status: MasterShareInvitationStatus;
+}
+/** One pending invitation, as the recipient's list renders it. */
+export interface PendingMasterShare {
+    share_id: number;
+    canvas_id: string;
+    canvas_name: string;
+    instance_id: string;
+    shared_by: MiniUser;
+    created_at: string;
+}
+export declare function pendingRowId(shareId: number): string;
+export declare function isPendingRowId(id?: string | number | null): boolean;
+/**
+ * The share id behind a pending row id, or `null` if it is not one.
+ *
+ * Digits only, deliberately: `Number('')` is `0` and `Number.isInteger(0)` is true, so a bare
+ * `'pending:'` used to parse to share id 0 — and `Number` also accepts whitespace, `0x` and
+ * exponent forms. Share ids are a positive `serial`, so anything else is a bug upstream and must
+ * read as "not a pending row" rather than as row 0.
+ */
+export declare function pendingShareIdFromRowId(id?: string | number | null): number | null;
+/**
+ * Shapes a pending invitation as a table row.
+ *
+ * `owned_by` carries the SHARER, which is what lets the existing Owner column render "who sent
+ * this" with no special-casing — for an invitation the only person worth naming is the sender.
+ * `is_master` keeps it consistent with the tab it appears on; every other canvas field is left
+ * absent so the remaining cells render empty rather than inventing state the invitation has not
+ * got (no tags, no progress, no modified date, no ready/draft status).
+ */
+export interface PendingMasterShareRow {
+    id: string;
+    name: string;
+    owned_by: MiniUser;
+    is_master: true;
+    created_at: string;
+    modified_at: string;
+    __pendingShare: PendingMasterShare;
+}
+export declare function toPendingRow(share: PendingMasterShare): PendingMasterShareRow;
+/**
+ * Pending invitations first, then the user's own masters.
+ *
+ * Prepended rather than sorted in: an invitation is an inbox item needing a decision, and the
+ * table's sort applies to the fetched page — a pending row sorted by `modified_at` would sink
+ * below the fold on a rep with many masters and never be seen.
+ *
+ * Returns the list unchanged when there is nothing pending, so the non-master variants and the
+ * common case allocate nothing.
+ */
+export declare function mergePendingRows<T extends {
+    id: string;
+}>(rows: T[], pending: PendingMasterShare[]): (T | PendingMasterShareRow)[];

package/lib/components/masterCanvases/masterCanvasShares.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/masterFromCanvas.use.d.ts

@@ -0,0 +1,122 @@
+import { CanvasRetrieve } from '../../../types/openapi';
+/**
+ * PIT-7488 block 3 — turning an existing pitchdeck into a master.
+ *
+ * The deck is DUPLICATED, never mutated: the rep keeps the deck they were presenting, and a new
+ * `is_master` copy appears on the master tab.
+ *
+ * **The promoter owns the master, always — so the create payload must OMIT `owned_by_id`**
+ * (PIT-8362; the payload itself is `buildMasterFromCanvasPayload`, beside its block-4 mirror in
+ * `createFromMaster.use`). Django declares that field
+ * `default=CreateOnlyDefault(CurrentUserDefault())`, so leaving it out is precisely what assigns
+ * the caller; sending anything is a transfer, which `CanvasOwnedByFieldValidator` 400s for anyone
+ * but an org/instance admin.
+ *
+ * This reverses block 3's original rule, so read the history before "fixing" it back. That rule
+ * kept the SOURCE deck's owner, on the reasoning that a master should stay attributed to whoever
+ * built the deck. Vontobel's validation rejected it: "My Master Pitchdecks" is a personal,
+ * RESTRICTED, owner-scoped tab that the promote flow navigates to on success, so a master owned by
+ * someone else lands in a tab it does not belong in — invisible to a rep (`filter_by_member_access`
+ * is `owned_by=me OR public`), and attributed to a stranger for an admin, who sees the whole
+ * instance anyway.
+ */
+/**
+ * Context keys that must NOT survive onto a master.
+ *
+ * A master is a reusable *source*, so anything baked into its context propagates to every deck
+ * built from it later — `{{user.name}}` would render whoever ran "Use as master" rather than the
+ * rep actually presenting. That is the wrong-identity-on-a-copy defect class, one step upstream, and it is the
+ * same reasoning that keeps the master download path from PATCHing `context`.
+ *
+ * This is a DENYLIST on purpose. `pitcher_canvas.context` is a free-form client-written
+ * JSONField that also carries customer-specific keys, so an allowlist would silently drop those,
+ * and would drop any config key added later — which is exactly how PIT-7473 broke the pitchdeck
+ * wizard. Failing this way round means a *new* identity key leaks until it is listed here, which
+ * shows up as a visibly wrong name on a deck and is a one-line fix.
+ */
+export declare const MASTER_CONTEXT_IDENTITY_KEYS: readonly ["user", "today", "Account", "salesforce_data", "Meeting", "pitcher_data", "analytics", "account", "meeting", "SelectedAccount"];
+/**
+ * Top-level context key FAMILIES that are identity, matched by prefix rather than by name.
+ *
+ * `ctx_overwrite_<slideIndex>` is written by the `react-salesforce-admin` populator
+ * (`public/populator.html:509-525`) and holds BOTH a `pitcher_data` and a `salesforce_data` copy of
+ * a matched customer record, scoped to one slide — the same two namespaces
+ * `MASTER_CONTEXT_IDENTITY_KEYS` already strips at the top level, one nesting deeper and therefore
+ * invisible to a literal-key `omit`. A master promoted from a rep's deck carried the promoter's
+ * customer (client name, ids, figures) onto every deck built from it, per slide (PIT-8399 review).
+ *
+ * The key count is unbounded (one per matched slide) and the names embed a component id, so this
+ * cannot be expressed as literals — hence a prefix list.
+ *
+ * **Not to be confused with `context.wizard.overwrite_<sectionListId>_<n>`**, which is the WIZARD's
+ * positional slide override (`buildStepUpdate`) and is curation a master must keep. The two are
+ * cleanly separable: the populator's lives at the top level, the wizard's inside `wizard`.
+ */
+export declare const MASTER_CONTEXT_IDENTITY_KEY_PREFIXES: readonly ["ctx_overwrite_"];
+/** Drops every top-level key matching one of the identity prefixes above. Non-mutating. */
+export declare function withoutPrefixedIdentityKeys(context: Record<string, unknown>): Record<string, unknown>;
+/**
+ * Whether a context carries a wizard artifact the restore could actually rebuild POINTS from.
+ *
+ * Mirrors the two — and only two — skeleton sources of the app's restore walk: the enrichment's
+ * per-point spans (`react_wizard.points`) and the vanilla group selections
+ * (`group_selections_<sectionListId>`). BOTH must be non-empty arrays: `for (const sel of
+ * selections)` and the enrichment loop each build zero skeletons from `[]`, so a present-but-empty
+ * key describes nothing. Checking only the selections KEY made this looser than the app's
+ * `fromArtifact` (which uses `selections.length > 0`) — and on the duplicate path, which has no
+ * second gate, looser means unguarded. Everything else under `wizard` is answers, cover picks or
+ * admin config: the live repro deck carries `selected_assets`, `selected_asset_url`, `selected_file`
+ * and `title`, and the populator reads a `wizard.dataIndexMap` — none of which can rebuild a point.
+ *
+ * So `!!context.wizard` is NOT the same question, and the difference bites hardest in
+ * `buildDuplicateContext`: its marker selects `react_saved`, which resolves to the EDIT flow, whose
+ * restore is deliberately ungated on the app's own `fromArtifact` check (a vanilla deck legitimately
+ * restores by attribution). A master whose `wizard` held only cover picks therefore opened with an
+ * agenda rebuilt by attribution — the PIT-7488 QA Q9 outcome — with nothing downstream to catch it
+ * (peer review F2).
+ *
+ * Deliberately WEAKER than the app's `fromArtifact`, which also requires the enrichment spans to
+ * partition the node's ref list. The host has no refs to hand here, so it answers "are there
+ * skeleton sources at all"; the app makes the precise call. That is the two-gate design, and it is
+ * why the two predicates are allowed to differ.
+ */
+export declare function hasRestorableArtifact(context?: Record<string, unknown> | null): boolean;
+/** Suffix appended to the source deck's name to seed the dialog. Matches the prototype. */
+export declare const MASTER_NAME_SUFFIX = "(master)";
+/**
+ * Strips the identity above out of `context.wizard`, leaving the curation intact.
+ *
+ * Non-mutating — `omit` returns a new object at every level this touches, so the source master's
+ * own context is never altered. A `wizard` (or a `react_wizard`) left with nothing in it is
+ * dropped rather than kept as `{}`, the same rule `withoutPitcherKeys` follows for
+ * `context.pitcher`. A context carrying no `wizard` at all is returned untouched, which is what
+ * makes this safe to compose onto every master-context builder.
+ *
+ * Deliberately does NOT touch `react_wizard.points` / `version`: `restoreAgenda` validates the
+ * enrichment by checking that its per-point `slide_count`s partition the node's ref list exactly,
+ * so pruning identity here cannot invalidate the artifact the agenda is rebuilt from.
+ */
+export declare function withoutWizardIdentity(context: Record<string, unknown>): Record<string, unknown>;
+/**
+ * The context to store on the new master: everything the source deck carried, minus identity.
+ *
+ * Identity is pruned at all THREE places it hides — the top-level keys above, the prefixed
+ * `ctx_overwrite_*` families (`withoutPrefixedIdentityKeys`), and the wizard artifact's own
+ * (`withoutWizardIdentity`). A master promoted from a deck the rep had run the
+ * wizard on carried the promoter's customer in `wizard.subtitle`, which deck templates render on
+ * the cover slide, so the top-level pass alone was not enough (PIT-8399).
+ *
+ * Deliberately NOT gated on `copy_context_to_canvas`. That flag exists because copying context
+ * wholesale was risky, and the risk was the identity keys stripped here — gating on it would
+ * hand flag-off instances a master with no `section_list_config`, reintroducing PIT-7473 for
+ * every deck built from it.
+ *
+ * Returns `undefined` rather than `{}` when nothing survives, so the create payload omits the
+ * field instead of writing an empty object over the server's default.
+ */
+export declare function buildMasterContext(context?: CanvasRetrieve['context'] | null): Record<string, unknown> | undefined;
+/**
+ * Seeds the dialog's name field. The rep can overwrite it; the suffix only exists so the master
+ * is distinguishable from the deck it came from in a list sorted by name.
+ */
+export declare function defaultMasterNameFor(sourceName?: string | null): string;

package/lib/components/masterCanvases/masterFromCanvas.use.spec.d.ts

@@ -0,0 +1 @@
+export {};

package/lib/components/masterCanvases/masterFromTemplate.use.d.ts

@@ -0,0 +1,50 @@
+import { CanvasCreateRequest, CanvasRetrieve } from '../../../types/openapi';
+/**
+ * PIT-7488 — creating a master FROM AN ADMIN TEMPLATE.
+ *
+ * The fourth and last of the master copy paths, and the one that was missing: block 3 is
+ * deck -> master (`buildMasterContext`), block 4 is master -> deck (`buildContextFromMaster`),
+ * block 5 is master -> shared copy (next-core's `buildSharedCopyContext`), and this is
+ * template -> master.
+ *
+ * It exists because **Django does not clone a template server-side.** `POST /canvases` stores
+ * `template_id` as a plain FK and nothing else, so every create path clones client-side —
+ * `canvas.create.ts` for pitchdecks, `buildCreateFromMasterPayload` for decks from masters. The
+ * master tab was the one path that never did, so a master built from a template was created
+ * EMPTY: no `content` means no `SectionList`/`ContentList` nodes, and
+ * `useCanvasCompletionWizard.isCompletionWizardEnabled` is `wizardSteps.length > 0`, so the
+ * pitchdeck wizard could never run on it either. One missing clone, two reported symptoms.
+ *
+ * Not built on `slotty-ui-ng`'s shared `createCanvas` util on purpose: that util assigns
+ * `content`/`theme`/`context` AFTER spreading the caller's payload, so a sanitized master context
+ * cannot be passed in — and what it writes instead is wrong in both flag states (with
+ * `copy_context_to_canvas` on it copies the template context wholesale, identity and completed
+ * wizard state included; with it off it writes `{}`, losing `section_list_config`). It also
+ * prompts for an account and merges CRM data into the context on orgs with
+ * `require_account_on_canvas_creation`, which no master may carry.
+ */
+/** The narrow slice of a fetched template this needs — request it as `fields=content,theme,context`. */
+export interface MasterTemplateSource extends Pick<CanvasRetrieve, 'content' | 'theme' | 'context'> {
+}
+/** The create-payload fields to spread over the master's own invariants. */
+export interface MasterFromTemplatePayload extends Pick<CanvasCreateRequest, 'content' | 'theme' | 'context'> {
+}
+/**
+ * Builds the `content`/`theme`/`context` a master should inherit from the template it was created
+ * from. Pure, non-mutating, and **deliberately ungated**.
+ *
+ * Not gated on `copy_context_to_canvas` for the same reason `buildMasterContext` is not: that flag
+ * exists because copying context wholesale was risky, and the risk *is* the identity keys stripped
+ * here. Gating on it would hand flag-off instances a master with no `section_list_config`, which is
+ * PIT-7473 reintroduced for every deck later built from that master.
+ *
+ * `metadata` is deliberately NOT copied. Nothing the wizard reads lives there, and a template's
+ * metadata carries its own bookkeeping — the async-download record (`job_id`, `pdf_url`, `pptx_url`,
+ * `conversion_date`) and `frozen_until`, which would make a brand-new master born read-only and
+ * offering a download of the TEMPLATE. Having none is the truthful state for a new master.
+ *
+ * Every field is omitted rather than emitted as `undefined`/`{}` when there is nothing to carry, so
+ * the no-template case ("New master pitchdeck") posts byte-identical to what it posts today instead
+ * of writing empty objects over the server's defaults.
+ */
+export declare function buildMasterFromTemplatePayload(template?: MasterTemplateSource | null): MasterFromTemplatePayload;

package/lib/components/masterCanvases/masterFromTemplate.use.spec.d.ts

@@ -0,0 +1 @@
+export {};