feat(memory): publish personal memories

[dcramer]

Users can now publish one of their personal memories from the Memories dashboard when that memory belongs to an identity with a provider workspace. The owner can still forget the published memory, while shared workspace knowledge remains view-only.

Memory model

A memory has two separate concerns:

• subjectType and subjectKey describe who or what it is about.
• scope and scopeKey describe who may recall it.

Explicit memory review now returns both kind and target, which allows an expiring availability fact to be knowledge about the current actor. Runtime keeps preferences actor-scoped and procedures conversation-scoped even if model review returns a conflicting target, so the model never controls identity keys or bypasses those ownership rules.

Publishing changes only the audience. Canonical content, provenance, and embeddings remain unchanged while the personal scope moves to the provider workspace scope.

Subject label snapshot

Publishing stores a nullable subject_label beside the structured user subject. This is presentation metadata, not authority and not embedding input. Memory-owned surfaces render canonical content such as Out of office August 10–14 as About Morgan: Out of office August 10–14 when model-visible self-contained text is required.

The same snapshot is used by automatic recall, list/search tools, REST responses, and dashboard records. REST preserves canonical content and adds a structured user subject. A public user memory without a label is omitted from model-visible recall and tool output rather than risk misattribution.

The tradeoff is deliberate: a later display-name change does not rewrite an existing memory. Expiring status memories make that acceptable for this MVP, and label refresh can be added later if proven necessary.

Ownership and actions

The memory page adds Make Public for publishable personal memories and retains owner-only Forget after publication. Owned public memories continue to say “You asked Junior”; shared public memories retain generic workspace language.

Ownership is also enforced in the low-level archive path. A public user-subject memory can be removed through the chat removeMemory tool only when its subject matches the current actor. Conversation-subject memory keeps the existing shared-memory behavior.

The shared plugin user-page action contract supports POST as well as DELETE, and memory exposes POST /api/plugins/memory/memories/:id/publish.

MVP boundary

• Publishing requires an identity with a provider workspace; local identities without one cannot publish.
• Publishing is dashboard-only; “remember publicly” chat wording is deferred.
• Owners can forget a published memory, but there is no make-private action yet.
• Workspace-public recall keeps the existing public-conversation boundary.
• Identity-name-only search is not added; retrieval still ranks canonical memory content.
• Automatic learning never publishes a personal memory.
• The nullable subject_label column requires the included memory migration.

Review should start with personal-store.ts for publication and dashboard ownership, store.ts for the low-level archive guard, and subjects.ts for the small presentation rule.

Coverage includes canonical-content publication, the stored subject label, identity-aware recall/tools/REST/dashboard output, owner and non-owner chat removal, out-of-office agent interpretation, migration metadata, and the Chromium dashboard publish flow. Focused tests, builds, typechecks, formatting, package lint, commit hooks, and the full pre-push suite pass.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
junior-docs	Ready	Preview	Aug 5, 2026 12:52am

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8b7a841. Configure here.}

[cursor]

Publishable ignores missing owner label

Medium Severity

publishable only checks workspace audience, while publish also requires a non-empty owner label from ownerLabels. When an identity has no displayName, handle, or user displayName, the dashboard still offers Make Public, then the publish API fails with a 400.

Additional Locations (2)

• packages/junior-memory/src/personal-store.ts#L402-L407
• packages/junior-memory/src/personal.ts#L102-L106

 

^{Reviewed by Cursor Bugbot for commit 8b7a841. Configure here.}

[cursor]

Name-first recall never sees labels

Medium Severity

Published memories keep canonical content without the person name, and presentedMemoryContent only adds About {label} after vector/lexical candidate retrieval. Name-first asks such as remembering someone by name therefore often never retrieve those workspace user memories, so the new subject label never reaches relevance selection.

Additional Locations (1)

• packages/junior-memory/src/subjects.ts#L3-L12

 

^{Reviewed by Cursor Bugbot for commit 8b7a841. Configure here.}