What

File, image, video, audio and bookmark objects are artifacts — created inside a document block, a chat, a collection, or as a cover/icon value — but their own page gave no way back to where they came from.

That link is genuinely unreachable otherwise: createdInContext sits in heart's relationsToSkipLinksIndexing, so the origin produces no backlink in either direction. If we don't render it, it's lost.

This adds an eyebrow above the title on media and bookmark pages, plus one navigation primitive that deep-links into the origin.

How

• 
  U.Object.openCreatedInContext — single entry point. Resolves the context from dependent details (already delivered on object open, so no extra fetch and no backend change), toasts and stops when the context is gone, and reveals in place when it's already the open object.


• 
  Ref meaning comes from the context's layout, not from probing the string: chat → message id; otherwise a relation key when getRelationByKey resolves, else a block id. Empty ref → the context root.


• 
  Reveal reuses what exists — U.Comment.scrollToBlock and the chat scrollToMessage event. The relation case is the only new behavior: it opens the right panel and highlights the row, waiting on a bounded raf poll (and on sidebar.isAnimating, since rightPanelToggle silently no-ops mid-animation) rather than guessing a timeout. Gives up silently instead of dead-clicking.


• 
  The createdInContext cell is special-cased (precedent: source in cell/index.tsx) so the property deep-links identically wherever it renders — Local group, Properties panel, featured chip — not just from the eyebrow.

Scope

Normal objects are deliberately unchanged. They already have a featured-relations row, which is the type-controlled mechanism for "what shows at the top of an object" — so they keep the property in the Properties panel's Local group and can promote it to the type. The eyebrow is hard-coded only on media pages, which render their own layout and have no featured row.

Bookmarks do have a featured row (they route through page.go, which applies WithFeaturedRelationsBlock unconditionally). The eyebrow is kept there as a product decision, since bookmarks were part of the original request; both affordances deep-link identically.

Not included, recorded in the spec: chat message-id stamping (the messageId doesn't exist at upload time, so a chat-origin file resolves to the chat but not the message — degrades gracefully), and one-step "add to type as featured".

Second commit — unrelated sidebar fix

Collapsing or expanding the vault left the space sidebar unresizable until a reload, while the same closed-vault state restored from storage worked fine.

resizePage applies sidebarAnimation via toggleClass, so it survives until the next non-animated resize, and leftPanelClose/leftPanelOpen never removed it — unlike leftPanelSubPageOpen/Close, which both strip it in their completion timeouts. Since .subPageWrapper.sidebarAnimation carries overflow: hidden and the resize handle is absolutely positioned outside the box at right: -12px, the leaked class clipped the handle away entirely. Reload cleared it because init() calls resizePage with animate = false.

Pre-existing, not caused by the feature; fixed here at request.

Verification

• 
  bun run typecheck — clean


• 
  bun run lint — clean on all touched files


• 74/74 unit tests pass (20 new covering ref derivation and primitive branching; also repairs object.test.ts, which was failing to load entirely — 0 → 54)

No component tests: vitest runs environment: 'node' here with no jsdom installed. Those conditions are covered by the Storybook story instead.

Testing notes

Worth exercising by hand: drop an image into a document block → open the image object → click the eyebrow (should scroll to that block and highlight). Also the vault fix — collapse the vault, then drag the space sidebar's right edge without reloading.

Design doc: docs/superpowers/specs/2026-08-23-created-in-context-navigation-design.md