@anuma/sdk 6.14.1 → 6.14.2

package/dist/expo/index.cjs

@@ -15438,7 +15438,7 @@ async function ingestPublishedPhotoMemoriesOp(ctx, rows) {
       ({ row, content }) => ctx.vaultMemoryCollection.prepareCreate((record) => {
         record._raw.id = row.memoryId;
         record._setRaw("content", content);
-        record._setRaw("scope", "private");
+        record._setRaw("scope", "shared");
         record._setRaw("folder_id", null);
         record._setRaw("user_id", ctx.userId ?? null);
         record._setRaw("is_deleted", false);

package/dist/expo/index.d.mts

@@ -6335,15 +6335,26 @@ declare function extractAndRetain(messages: AutoExtractMessage[], retainCtx: Ret
 }>;
 
 /**
- * People Nearby cross-user visibility. ORTHOGONAL to `scope` (model access):
- * - `private`: local-only (default; null column grandfathered as private)
- * - `public`: embedding + plaintext may be published (compatibility matching,
- *   profile display, discovery answers, digital-twin prompts)
+ * LEGACY. This column no longer decides anything.
+ *
+ * `scope === 'shared'` is now the single publication axis: it means the memory
+ * is on the People Nearby profile, its text goes to the nearby server, and it
+ * may inform what strangers see. `scope: 'private'` means it is not. There is
+ * no second control, and scope no longer gates model access either — every
+ * model tier reads every memory. Do NOT reason about publication from this
+ * type; read `scope`.
+ *
+ * The column survives in the schema and is still stamped on writes so that
+ * stored rows stay readable by builds that predate the change. Nothing on a
+ * current build reads it to make a decision.
+ *
+ * Values, kept for tolerance of already-stored data:
+ * - `private`: local-only (a null column reads as private)
+ * - `public`: the row was published
  *
  * TWO TIERS ONLY (decided 2026-07-27). An earlier design had a middle
  * `matchable` tier that published a memory's embedding while keeping its text
- * on-device; it was dropped, so a memory either never leaves the device or is
- * published with its content. Any unrecognised stored value — including a
+ * on-device; it was dropped. Any unrecognised stored value — including a
  * `matchable` row written by a pre-release build — reads as `private`, which is
  * the fail-safe direction: it un-publishes rather than exposes.
  */
@@ -6997,12 +7008,16 @@ declare function updateVaultMemoryEmbeddingOp(ctx: VaultMemoryOperationsContext,
  *     candidate to be reconciled against the vault — it is an already-decided
  *     fact the server has published.
  *
- * The rows are written `visibility: "public"` because they genuinely ARE
- * published — the reconciler reads local visibility as the user's intent, and
- * anything else would make it immediately revoke a memory the user never turned
- * off. They carry `source: SOURCE_PHOTO`, which is what exempts them from
- * decay's auto-archive; see the note there for why archiving one would silently
- * unpublish it.
+ * The rows are written `scope: "shared"` because they genuinely ARE published.
+ * `scope === 'shared'` is the publication axis — the single one. The reconciler
+ * reads local scope as the user's intent, and it builds its `local` set from a
+ * vault read narrowed to `{scopes: ['shared']}`. A row stamped anything else
+ * never enters that read, so it is never adopted into the publish ledger, and
+ * `toRevoke` is computed only over ids the ledger holds. The user's off-toggle
+ * would then do nothing server-side while nearby kept serving the memory. The
+ * `visibility` column is legacy: nothing reads it any more. They carry
+ * `source: SOURCE_PHOTO`, which is what exempts them from decay's auto-archive;
+ * see the note there for why archiving one would silently unpublish it.
  *
  * No embedding is computed here. `searchTool`'s un-embedded lane embeds any row
  * lacking a vector at search time, uses it in that same search and persists it
@@ -7050,6 +7065,29 @@ interface PhotoIngestResult {
  * class of bug as publishing a version the user has since changed. Re-ingesting
  * changed text is a follow-up that needs a merge decision, not a clobber.
  *
+ * That skip is also why this op does NOT repair a row an older build stamped
+ * `scope: "private"`. Such a row is present, so ingest leaves it alone, and it
+ * stays outside the published-set read. The user's switch cannot revoke it.
+ * Repair belongs in a one-time pass at upgrade. Do not add it here, for two
+ * reasons:
+ *
+ *  - **The two states are indistinguishable from this op.** After this build a
+ *    `photo:` row with `scope: "private"` is also exactly what the user's own
+ *    off-toggle produces. The toggle calls `updateVaultMemoryOp`, which writes
+ *    `scope` and never touches `visibility`, so the mis-stamped row and the
+ *    turned-off row carry identical columns. No test here can tell them apart.
+ *
+ *  - **A re-stamp here would revert the off-toggle.** The pass runs ingest
+ *    BEFORE it reads the vault, so a row re-stamped `shared` re-enters the
+ *    desired set on that same pass and never reaches `toRevoke`. The switch
+ *    would spring back to "on" and nearby would keep serving the memory. That
+ *    is worse than the bug it repairs.
+ *
+ * A one-time pass does not have the ambiguity. Before this build the switch
+ * already read "off" for these rows, because it reads `scope`, so no user can
+ * have turned one off. Every `private` photo row at that instant came from the
+ * old stamp.
+ *
  * Non-`photo:` ids are ignored: everything else in the published set is a
  * client-published memory that by definition already lives in this vault (or in
  * another device's, which is not ours to recreate).

package/dist/expo/index.d.ts

@@ -6335,15 +6335,26 @@ declare function extractAndRetain(messages: AutoExtractMessage[], retainCtx: Ret
 }>;
 
 /**
- * People Nearby cross-user visibility. ORTHOGONAL to `scope` (model access):
- * - `private`: local-only (default; null column grandfathered as private)
- * - `public`: embedding + plaintext may be published (compatibility matching,
- *   profile display, discovery answers, digital-twin prompts)
+ * LEGACY. This column no longer decides anything.
+ *
+ * `scope === 'shared'` is now the single publication axis: it means the memory
+ * is on the People Nearby profile, its text goes to the nearby server, and it
+ * may inform what strangers see. `scope: 'private'` means it is not. There is
+ * no second control, and scope no longer gates model access either — every
+ * model tier reads every memory. Do NOT reason about publication from this
+ * type; read `scope`.
+ *
+ * The column survives in the schema and is still stamped on writes so that
+ * stored rows stay readable by builds that predate the change. Nothing on a
+ * current build reads it to make a decision.
+ *
+ * Values, kept for tolerance of already-stored data:
+ * - `private`: local-only (a null column reads as private)
+ * - `public`: the row was published
  *
  * TWO TIERS ONLY (decided 2026-07-27). An earlier design had a middle
  * `matchable` tier that published a memory's embedding while keeping its text
- * on-device; it was dropped, so a memory either never leaves the device or is
- * published with its content. Any unrecognised stored value — including a
+ * on-device; it was dropped. Any unrecognised stored value — including a
  * `matchable` row written by a pre-release build — reads as `private`, which is
  * the fail-safe direction: it un-publishes rather than exposes.
  */
@@ -6997,12 +7008,16 @@ declare function updateVaultMemoryEmbeddingOp(ctx: VaultMemoryOperationsContext,
  *     candidate to be reconciled against the vault — it is an already-decided
  *     fact the server has published.
  *
- * The rows are written `visibility: "public"` because they genuinely ARE
- * published — the reconciler reads local visibility as the user's intent, and
- * anything else would make it immediately revoke a memory the user never turned
- * off. They carry `source: SOURCE_PHOTO`, which is what exempts them from
- * decay's auto-archive; see the note there for why archiving one would silently
- * unpublish it.
+ * The rows are written `scope: "shared"` because they genuinely ARE published.
+ * `scope === 'shared'` is the publication axis — the single one. The reconciler
+ * reads local scope as the user's intent, and it builds its `local` set from a
+ * vault read narrowed to `{scopes: ['shared']}`. A row stamped anything else
+ * never enters that read, so it is never adopted into the publish ledger, and
+ * `toRevoke` is computed only over ids the ledger holds. The user's off-toggle
+ * would then do nothing server-side while nearby kept serving the memory. The
+ * `visibility` column is legacy: nothing reads it any more. They carry
+ * `source: SOURCE_PHOTO`, which is what exempts them from decay's auto-archive;
+ * see the note there for why archiving one would silently unpublish it.
  *
  * No embedding is computed here. `searchTool`'s un-embedded lane embeds any row
  * lacking a vector at search time, uses it in that same search and persists it
@@ -7050,6 +7065,29 @@ interface PhotoIngestResult {
  * class of bug as publishing a version the user has since changed. Re-ingesting
  * changed text is a follow-up that needs a merge decision, not a clobber.
  *
+ * That skip is also why this op does NOT repair a row an older build stamped
+ * `scope: "private"`. Such a row is present, so ingest leaves it alone, and it
+ * stays outside the published-set read. The user's switch cannot revoke it.
+ * Repair belongs in a one-time pass at upgrade. Do not add it here, for two
+ * reasons:
+ *
+ *  - **The two states are indistinguishable from this op.** After this build a
+ *    `photo:` row with `scope: "private"` is also exactly what the user's own
+ *    off-toggle produces. The toggle calls `updateVaultMemoryOp`, which writes
+ *    `scope` and never touches `visibility`, so the mis-stamped row and the
+ *    turned-off row carry identical columns. No test here can tell them apart.
+ *
+ *  - **A re-stamp here would revert the off-toggle.** The pass runs ingest
+ *    BEFORE it reads the vault, so a row re-stamped `shared` re-enters the
+ *    desired set on that same pass and never reaches `toRevoke`. The switch
+ *    would spring back to "on" and nearby would keep serving the memory. That
+ *    is worse than the bug it repairs.
+ *
+ * A one-time pass does not have the ambiguity. Before this build the switch
+ * already read "off" for these rows, because it reads `scope`, so no user can
+ * have turned one off. Every `private` photo row at that instant came from the
+ * old stamp.
+ *
  * Non-`photo:` ids are ignored: everything else in the published set is a
  * client-published memory that by definition already lives in this vault (or in
  * another device's, which is not ours to recreate).

package/dist/expo/index.mjs

@@ -5819,7 +5819,7 @@ async function ingestPublishedPhotoMemoriesOp(ctx, rows) {
       ({ row, content }) => ctx.vaultMemoryCollection.prepareCreate((record) => {
         record._raw.id = row.memoryId;
         record._setRaw("content", content);
-        record._setRaw("scope", "private");
+        record._setRaw("scope", "shared");
         record._setRaw("folder_id", null);
         record._setRaw("user_id", ctx.userId ?? null);
         record._setRaw("is_deleted", false);

package/dist/react/index.cjs

@@ -17076,7 +17076,7 @@ async function ingestPublishedPhotoMemoriesOp(ctx, rows) {
       ({ row, content }) => ctx.vaultMemoryCollection.prepareCreate((record) => {
         record._raw.id = row.memoryId;
         record._setRaw("content", content);
-        record._setRaw("scope", "private");
+        record._setRaw("scope", "shared");
         record._setRaw("folder_id", null);
         record._setRaw("user_id", ctx.userId ?? null);
         record._setRaw("is_deleted", false);

package/dist/react/index.d.mts

@@ -7604,15 +7604,26 @@ declare function extractAndRetain(messages: AutoExtractMessage[], retainCtx: Ret
 }>;
 
 /**
- * People Nearby cross-user visibility. ORTHOGONAL to `scope` (model access):
- * - `private`: local-only (default; null column grandfathered as private)
- * - `public`: embedding + plaintext may be published (compatibility matching,
- *   profile display, discovery answers, digital-twin prompts)
+ * LEGACY. This column no longer decides anything.
+ *
+ * `scope === 'shared'` is now the single publication axis: it means the memory
+ * is on the People Nearby profile, its text goes to the nearby server, and it
+ * may inform what strangers see. `scope: 'private'` means it is not. There is
+ * no second control, and scope no longer gates model access either — every
+ * model tier reads every memory. Do NOT reason about publication from this
+ * type; read `scope`.
+ *
+ * The column survives in the schema and is still stamped on writes so that
+ * stored rows stay readable by builds that predate the change. Nothing on a
+ * current build reads it to make a decision.
+ *
+ * Values, kept for tolerance of already-stored data:
+ * - `private`: local-only (a null column reads as private)
+ * - `public`: the row was published
  *
  * TWO TIERS ONLY (decided 2026-07-27). An earlier design had a middle
  * `matchable` tier that published a memory's embedding while keeping its text
- * on-device; it was dropped, so a memory either never leaves the device or is
- * published with its content. Any unrecognised stored value — including a
+ * on-device; it was dropped. Any unrecognised stored value — including a
  * `matchable` row written by a pre-release build — reads as `private`, which is
  * the fail-safe direction: it un-publishes rather than exposes.
  */
@@ -8352,12 +8363,16 @@ declare function updateVaultMemoryEmbeddingOp(ctx: VaultMemoryOperationsContext,
  *     candidate to be reconciled against the vault — it is an already-decided
  *     fact the server has published.
  *
- * The rows are written `visibility: "public"` because they genuinely ARE
- * published — the reconciler reads local visibility as the user's intent, and
- * anything else would make it immediately revoke a memory the user never turned
- * off. They carry `source: SOURCE_PHOTO`, which is what exempts them from
- * decay's auto-archive; see the note there for why archiving one would silently
- * unpublish it.
+ * The rows are written `scope: "shared"` because they genuinely ARE published.
+ * `scope === 'shared'` is the publication axis — the single one. The reconciler
+ * reads local scope as the user's intent, and it builds its `local` set from a
+ * vault read narrowed to `{scopes: ['shared']}`. A row stamped anything else
+ * never enters that read, so it is never adopted into the publish ledger, and
+ * `toRevoke` is computed only over ids the ledger holds. The user's off-toggle
+ * would then do nothing server-side while nearby kept serving the memory. The
+ * `visibility` column is legacy: nothing reads it any more. They carry
+ * `source: SOURCE_PHOTO`, which is what exempts them from decay's auto-archive;
+ * see the note there for why archiving one would silently unpublish it.
  *
  * No embedding is computed here. `searchTool`'s un-embedded lane embeds any row
  * lacking a vector at search time, uses it in that same search and persists it
@@ -8405,6 +8420,29 @@ interface PhotoIngestResult {
  * class of bug as publishing a version the user has since changed. Re-ingesting
  * changed text is a follow-up that needs a merge decision, not a clobber.
  *
+ * That skip is also why this op does NOT repair a row an older build stamped
+ * `scope: "private"`. Such a row is present, so ingest leaves it alone, and it
+ * stays outside the published-set read. The user's switch cannot revoke it.
+ * Repair belongs in a one-time pass at upgrade. Do not add it here, for two
+ * reasons:
+ *
+ *  - **The two states are indistinguishable from this op.** After this build a
+ *    `photo:` row with `scope: "private"` is also exactly what the user's own
+ *    off-toggle produces. The toggle calls `updateVaultMemoryOp`, which writes
+ *    `scope` and never touches `visibility`, so the mis-stamped row and the
+ *    turned-off row carry identical columns. No test here can tell them apart.
+ *
+ *  - **A re-stamp here would revert the off-toggle.** The pass runs ingest
+ *    BEFORE it reads the vault, so a row re-stamped `shared` re-enters the
+ *    desired set on that same pass and never reaches `toRevoke`. The switch
+ *    would spring back to "on" and nearby would keep serving the memory. That
+ *    is worse than the bug it repairs.
+ *
+ * A one-time pass does not have the ambiguity. Before this build the switch
+ * already read "off" for these rows, because it reads `scope`, so no user can
+ * have turned one off. Every `private` photo row at that instant came from the
+ * old stamp.
+ *
  * Non-`photo:` ids are ignored: everything else in the published set is a
  * client-published memory that by definition already lives in this vault (or in
  * another device's, which is not ours to recreate).

package/dist/react/index.d.ts

@@ -7604,15 +7604,26 @@ declare function extractAndRetain(messages: AutoExtractMessage[], retainCtx: Ret
 }>;
 
 /**
- * People Nearby cross-user visibility. ORTHOGONAL to `scope` (model access):
- * - `private`: local-only (default; null column grandfathered as private)
- * - `public`: embedding + plaintext may be published (compatibility matching,
- *   profile display, discovery answers, digital-twin prompts)
+ * LEGACY. This column no longer decides anything.
+ *
+ * `scope === 'shared'` is now the single publication axis: it means the memory
+ * is on the People Nearby profile, its text goes to the nearby server, and it
+ * may inform what strangers see. `scope: 'private'` means it is not. There is
+ * no second control, and scope no longer gates model access either — every
+ * model tier reads every memory. Do NOT reason about publication from this
+ * type; read `scope`.
+ *
+ * The column survives in the schema and is still stamped on writes so that
+ * stored rows stay readable by builds that predate the change. Nothing on a
+ * current build reads it to make a decision.
+ *
+ * Values, kept for tolerance of already-stored data:
+ * - `private`: local-only (a null column reads as private)
+ * - `public`: the row was published
  *
  * TWO TIERS ONLY (decided 2026-07-27). An earlier design had a middle
  * `matchable` tier that published a memory's embedding while keeping its text
- * on-device; it was dropped, so a memory either never leaves the device or is
- * published with its content. Any unrecognised stored value — including a
+ * on-device; it was dropped. Any unrecognised stored value — including a
  * `matchable` row written by a pre-release build — reads as `private`, which is
  * the fail-safe direction: it un-publishes rather than exposes.
  */
@@ -8352,12 +8363,16 @@ declare function updateVaultMemoryEmbeddingOp(ctx: VaultMemoryOperationsContext,
  *     candidate to be reconciled against the vault — it is an already-decided
  *     fact the server has published.
  *
- * The rows are written `visibility: "public"` because they genuinely ARE
- * published — the reconciler reads local visibility as the user's intent, and
- * anything else would make it immediately revoke a memory the user never turned
- * off. They carry `source: SOURCE_PHOTO`, which is what exempts them from
- * decay's auto-archive; see the note there for why archiving one would silently
- * unpublish it.
+ * The rows are written `scope: "shared"` because they genuinely ARE published.
+ * `scope === 'shared'` is the publication axis — the single one. The reconciler
+ * reads local scope as the user's intent, and it builds its `local` set from a
+ * vault read narrowed to `{scopes: ['shared']}`. A row stamped anything else
+ * never enters that read, so it is never adopted into the publish ledger, and
+ * `toRevoke` is computed only over ids the ledger holds. The user's off-toggle
+ * would then do nothing server-side while nearby kept serving the memory. The
+ * `visibility` column is legacy: nothing reads it any more. They carry
+ * `source: SOURCE_PHOTO`, which is what exempts them from decay's auto-archive;
+ * see the note there for why archiving one would silently unpublish it.
  *
  * No embedding is computed here. `searchTool`'s un-embedded lane embeds any row
  * lacking a vector at search time, uses it in that same search and persists it
@@ -8405,6 +8420,29 @@ interface PhotoIngestResult {
  * class of bug as publishing a version the user has since changed. Re-ingesting
  * changed text is a follow-up that needs a merge decision, not a clobber.
  *
+ * That skip is also why this op does NOT repair a row an older build stamped
+ * `scope: "private"`. Such a row is present, so ingest leaves it alone, and it
+ * stays outside the published-set read. The user's switch cannot revoke it.
+ * Repair belongs in a one-time pass at upgrade. Do not add it here, for two
+ * reasons:
+ *
+ *  - **The two states are indistinguishable from this op.** After this build a
+ *    `photo:` row with `scope: "private"` is also exactly what the user's own
+ *    off-toggle produces. The toggle calls `updateVaultMemoryOp`, which writes
+ *    `scope` and never touches `visibility`, so the mis-stamped row and the
+ *    turned-off row carry identical columns. No test here can tell them apart.
+ *
+ *  - **A re-stamp here would revert the off-toggle.** The pass runs ingest
+ *    BEFORE it reads the vault, so a row re-stamped `shared` re-enters the
+ *    desired set on that same pass and never reaches `toRevoke`. The switch
+ *    would spring back to "on" and nearby would keep serving the memory. That
+ *    is worse than the bug it repairs.
+ *
+ * A one-time pass does not have the ambiguity. Before this build the switch
+ * already read "off" for these rows, because it reads `scope`, so no user can
+ * have turned one off. Every `private` photo row at that instant came from the
+ * old stamp.
+ *
  * Non-`photo:` ids are ignored: everything else in the published set is a
  * client-published memory that by definition already lives in this vault (or in
  * another device's, which is not ours to recreate).

package/dist/react/index.mjs

@@ -6976,7 +6976,7 @@ async function ingestPublishedPhotoMemoriesOp(ctx, rows) {
       ({ row, content }) => ctx.vaultMemoryCollection.prepareCreate((record) => {
         record._raw.id = row.memoryId;
         record._setRaw("content", content);
-        record._setRaw("scope", "private");
+        record._setRaw("scope", "shared");
         record._setRaw("folder_id", null);
         record._setRaw("user_id", ctx.userId ?? null);
         record._setRaw("is_deleted", false);

package/dist/server/index.cjs

@@ -27426,7 +27426,7 @@ async function ingestPublishedPhotoMemoriesOp(ctx, rows) {
       ({ row, content }) => ctx.vaultMemoryCollection.prepareCreate((record) => {
         record._raw.id = row.memoryId;
         record._setRaw("content", content);
-        record._setRaw("scope", "private");
+        record._setRaw("scope", "shared");
         record._setRaw("folder_id", null);
         record._setRaw("user_id", ctx.userId ?? null);
         record._setRaw("is_deleted", false);

package/dist/server/index.d.mts

@@ -6253,15 +6253,26 @@ declare function extractAndRetain(messages: AutoExtractMessage[], retainCtx: Ret
 }>;
 
 /**
- * People Nearby cross-user visibility. ORTHOGONAL to `scope` (model access):
- * - `private`: local-only (default; null column grandfathered as private)
- * - `public`: embedding + plaintext may be published (compatibility matching,
- *   profile display, discovery answers, digital-twin prompts)
+ * LEGACY. This column no longer decides anything.
+ *
+ * `scope === 'shared'` is now the single publication axis: it means the memory
+ * is on the People Nearby profile, its text goes to the nearby server, and it
+ * may inform what strangers see. `scope: 'private'` means it is not. There is
+ * no second control, and scope no longer gates model access either — every
+ * model tier reads every memory. Do NOT reason about publication from this
+ * type; read `scope`.
+ *
+ * The column survives in the schema and is still stamped on writes so that
+ * stored rows stay readable by builds that predate the change. Nothing on a
+ * current build reads it to make a decision.
+ *
+ * Values, kept for tolerance of already-stored data:
+ * - `private`: local-only (a null column reads as private)
+ * - `public`: the row was published
  *
  * TWO TIERS ONLY (decided 2026-07-27). An earlier design had a middle
  * `matchable` tier that published a memory's embedding while keeping its text
- * on-device; it was dropped, so a memory either never leaves the device or is
- * published with its content. Any unrecognised stored value — including a
+ * on-device; it was dropped. Any unrecognised stored value — including a
  * `matchable` row written by a pre-release build — reads as `private`, which is
  * the fail-safe direction: it un-publishes rather than exposes.
  */
@@ -6853,12 +6864,16 @@ declare function updateVaultMemoryEmbeddingOp(ctx: VaultMemoryOperationsContext,
  *     candidate to be reconciled against the vault — it is an already-decided
  *     fact the server has published.
  *
- * The rows are written `visibility: "public"` because they genuinely ARE
- * published — the reconciler reads local visibility as the user's intent, and
- * anything else would make it immediately revoke a memory the user never turned
- * off. They carry `source: SOURCE_PHOTO`, which is what exempts them from
- * decay's auto-archive; see the note there for why archiving one would silently
- * unpublish it.
+ * The rows are written `scope: "shared"` because they genuinely ARE published.
+ * `scope === 'shared'` is the publication axis — the single one. The reconciler
+ * reads local scope as the user's intent, and it builds its `local` set from a
+ * vault read narrowed to `{scopes: ['shared']}`. A row stamped anything else
+ * never enters that read, so it is never adopted into the publish ledger, and
+ * `toRevoke` is computed only over ids the ledger holds. The user's off-toggle
+ * would then do nothing server-side while nearby kept serving the memory. The
+ * `visibility` column is legacy: nothing reads it any more. They carry
+ * `source: SOURCE_PHOTO`, which is what exempts them from decay's auto-archive;
+ * see the note there for why archiving one would silently unpublish it.
  *
  * No embedding is computed here. `searchTool`'s un-embedded lane embeds any row
  * lacking a vector at search time, uses it in that same search and persists it
@@ -6906,6 +6921,29 @@ interface PhotoIngestResult {
  * class of bug as publishing a version the user has since changed. Re-ingesting
  * changed text is a follow-up that needs a merge decision, not a clobber.
  *
+ * That skip is also why this op does NOT repair a row an older build stamped
+ * `scope: "private"`. Such a row is present, so ingest leaves it alone, and it
+ * stays outside the published-set read. The user's switch cannot revoke it.
+ * Repair belongs in a one-time pass at upgrade. Do not add it here, for two
+ * reasons:
+ *
+ *  - **The two states are indistinguishable from this op.** After this build a
+ *    `photo:` row with `scope: "private"` is also exactly what the user's own
+ *    off-toggle produces. The toggle calls `updateVaultMemoryOp`, which writes
+ *    `scope` and never touches `visibility`, so the mis-stamped row and the
+ *    turned-off row carry identical columns. No test here can tell them apart.
+ *
+ *  - **A re-stamp here would revert the off-toggle.** The pass runs ingest
+ *    BEFORE it reads the vault, so a row re-stamped `shared` re-enters the
+ *    desired set on that same pass and never reaches `toRevoke`. The switch
+ *    would spring back to "on" and nearby would keep serving the memory. That
+ *    is worse than the bug it repairs.
+ *
+ * A one-time pass does not have the ambiguity. Before this build the switch
+ * already read "off" for these rows, because it reads `scope`, so no user can
+ * have turned one off. Every `private` photo row at that instant came from the
+ * old stamp.
+ *
  * Non-`photo:` ids are ignored: everything else in the published set is a
  * client-published memory that by definition already lives in this vault (or in
  * another device's, which is not ours to recreate).

package/dist/server/index.d.ts

@@ -6253,15 +6253,26 @@ declare function extractAndRetain(messages: AutoExtractMessage[], retainCtx: Ret
 }>;
 
 /**
- * People Nearby cross-user visibility. ORTHOGONAL to `scope` (model access):
- * - `private`: local-only (default; null column grandfathered as private)
- * - `public`: embedding + plaintext may be published (compatibility matching,
- *   profile display, discovery answers, digital-twin prompts)
+ * LEGACY. This column no longer decides anything.
+ *
+ * `scope === 'shared'` is now the single publication axis: it means the memory
+ * is on the People Nearby profile, its text goes to the nearby server, and it
+ * may inform what strangers see. `scope: 'private'` means it is not. There is
+ * no second control, and scope no longer gates model access either — every
+ * model tier reads every memory. Do NOT reason about publication from this
+ * type; read `scope`.
+ *
+ * The column survives in the schema and is still stamped on writes so that
+ * stored rows stay readable by builds that predate the change. Nothing on a
+ * current build reads it to make a decision.
+ *
+ * Values, kept for tolerance of already-stored data:
+ * - `private`: local-only (a null column reads as private)
+ * - `public`: the row was published
  *
  * TWO TIERS ONLY (decided 2026-07-27). An earlier design had a middle
  * `matchable` tier that published a memory's embedding while keeping its text
- * on-device; it was dropped, so a memory either never leaves the device or is
- * published with its content. Any unrecognised stored value — including a
+ * on-device; it was dropped. Any unrecognised stored value — including a
  * `matchable` row written by a pre-release build — reads as `private`, which is
  * the fail-safe direction: it un-publishes rather than exposes.
  */
@@ -6853,12 +6864,16 @@ declare function updateVaultMemoryEmbeddingOp(ctx: VaultMemoryOperationsContext,
  *     candidate to be reconciled against the vault — it is an already-decided
  *     fact the server has published.
  *
- * The rows are written `visibility: "public"` because they genuinely ARE
- * published — the reconciler reads local visibility as the user's intent, and
- * anything else would make it immediately revoke a memory the user never turned
- * off. They carry `source: SOURCE_PHOTO`, which is what exempts them from
- * decay's auto-archive; see the note there for why archiving one would silently
- * unpublish it.
+ * The rows are written `scope: "shared"` because they genuinely ARE published.
+ * `scope === 'shared'` is the publication axis — the single one. The reconciler
+ * reads local scope as the user's intent, and it builds its `local` set from a
+ * vault read narrowed to `{scopes: ['shared']}`. A row stamped anything else
+ * never enters that read, so it is never adopted into the publish ledger, and
+ * `toRevoke` is computed only over ids the ledger holds. The user's off-toggle
+ * would then do nothing server-side while nearby kept serving the memory. The
+ * `visibility` column is legacy: nothing reads it any more. They carry
+ * `source: SOURCE_PHOTO`, which is what exempts them from decay's auto-archive;
+ * see the note there for why archiving one would silently unpublish it.
  *
  * No embedding is computed here. `searchTool`'s un-embedded lane embeds any row
  * lacking a vector at search time, uses it in that same search and persists it
@@ -6906,6 +6921,29 @@ interface PhotoIngestResult {
  * class of bug as publishing a version the user has since changed. Re-ingesting
  * changed text is a follow-up that needs a merge decision, not a clobber.
  *
+ * That skip is also why this op does NOT repair a row an older build stamped
+ * `scope: "private"`. Such a row is present, so ingest leaves it alone, and it
+ * stays outside the published-set read. The user's switch cannot revoke it.
+ * Repair belongs in a one-time pass at upgrade. Do not add it here, for two
+ * reasons:
+ *
+ *  - **The two states are indistinguishable from this op.** After this build a
+ *    `photo:` row with `scope: "private"` is also exactly what the user's own
+ *    off-toggle produces. The toggle calls `updateVaultMemoryOp`, which writes
+ *    `scope` and never touches `visibility`, so the mis-stamped row and the
+ *    turned-off row carry identical columns. No test here can tell them apart.
+ *
+ *  - **A re-stamp here would revert the off-toggle.** The pass runs ingest
+ *    BEFORE it reads the vault, so a row re-stamped `shared` re-enters the
+ *    desired set on that same pass and never reaches `toRevoke`. The switch
+ *    would spring back to "on" and nearby would keep serving the memory. That
+ *    is worse than the bug it repairs.
+ *
+ * A one-time pass does not have the ambiguity. Before this build the switch
+ * already read "off" for these rows, because it reads `scope`, so no user can
+ * have turned one off. Every `private` photo row at that instant came from the
+ * old stamp.
+ *
  * Non-`photo:` ids are ignored: everything else in the published set is a
  * client-published memory that by definition already lives in this vault (or in
  * another device's, which is not ours to recreate).

package/dist/server/index.mjs

@@ -3736,7 +3736,7 @@ async function ingestPublishedPhotoMemoriesOp(ctx, rows) {
       ({ row, content }) => ctx.vaultMemoryCollection.prepareCreate((record) => {
         record._raw.id = row.memoryId;
         record._setRaw("content", content);
-        record._setRaw("scope", "private");
+        record._setRaw("scope", "shared");
         record._setRaw("folder_id", null);
         record._setRaw("user_id", ctx.userId ?? null);
         record._setRaw("is_deleted", false);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anuma/sdk",
-  "version": "6.14.1",
+  "version": "6.14.2",
   "description": "",
   "main": "./dist/index.cjs",
   "module": "./dist/index.mjs",