Case Study

Component Atlas

A live, tenant-wide view of where every rendering and datasource is used — running entirely in the Pages iframe with no backend and no persisted index.

Case Study5 min read

The question editors keep asking

"If I publish, modify, or delete this rendering — or this datasource — what else breaks?" Native Pages does not surface cross-page rendering and datasource usage in a fast, in-context way. Editors fall back to manual hand-traversal in another tool, pre-deletion verification stalls, and pre-publish edits ship with hidden impact.

Component Atlas closes that gap with two surfaces shipped from one app registration:

  • A Dashboard Widget for component-centric search — type a rendering name, see every page that uses it, drill into per-page detail with a side drawer.
  • A Page Context Panel for page-centric impact — for the active page, list its renderings with +N other pages counters, plus a Datasource Impact group that does the same for every datasource referenced from this page.
2
surfaces from
one app
3
SDK endpoints
walked per scan
0
persisted
state
8
pages/sec
concurrency

How it actually works

The atlas is pull-only by design — the Marketplace SDK doesn't let apps intercept publish or delete actions in Pages — and fully live in the iframe. A scan walks the tenant from sites to pages to the components on each page on demand, and aggregates the results into a tenant-wide map of (rendering · datasource) → using pages.

Per-page failures are recorded with a typed reason (forbidden, timeout, not found, network error, other) so a single 403 never aborts the whole scan. Eight pages run in parallel for throughput, and a single Cancel button stops the in-flight scan everywhere at once. Partial results survive cancellation and stay clickable.

The atlas is built fresh on demand, cached for the tab's lifetime, and discarded on tab close. No backend, no persisted index, no scheduled jobs.

Why two surfaces, one app

Build · 03

The two-surface bet

2026-04-28 · Dashboard Widget + Pages Context Panel

Component-centric and page-centric impact are two views of the same atlas. One scan feeds both — installing the app twice would have doubled the cost without doubling the value.

  • One app registration, two extension points — a Cloud Portal Dashboard Widget for the search surface and a Pages Context Panel for the page-impact surface. Both surfaces share the same atlas module.
  • Iframe-only architecture — runs entirely in the browser through the Marketplace SDK. No backend, no external store, no cron. Threat surface stays narrow; rollout stays simple.
  • Identity by item ID — display-name collisions disambiguate via a short ID suffix in the row, with the full ID in a tooltip. Editors see names; IDs are there when needed.
  • Direct bindings only in v1 — datasource counts include only the bindings the API returns directly. Inherited, personalized, and A/B-variant bindings are explicitly out of scope, with a visible "Direct bindings only" affordance so editors aren't misled.
  • No anti-metrics — a ship-time gate blocks vanity dashboard counters (scans/minute, API calls served) from the codebase. The app reports impact, not throughput.

What the build crossed

This was the third product through the full agentic pipeline after PageShot and QuickCopy. The skill set held — the heavy lift this time was architectural: how do you make a tenant-scale scan feel calm in an iframe that has no idea how many pages are coming?

The answer ended up being a branded loading experience and a session-scoped cache: the scan kicks off with a phase progress, the editor can cancel without losing partial results, and a warm atlas serves the next click in under 2s instead of going back to the network.

Where this leaves the loop

Component Atlas is the third Marketplace product shipped end-to-end through /create-prd → /architect → /task-breakdown → /implement → /code-review → /test → /document → /ship. PageShot proved the skills hold under integral pressure. QuickCopy proved the patches survived a clean second build. Atlas proved the same skill set scales from a five-button panel to a tenant-wide live atlas without re-patching.

For the methodology that produced this state, see the dogfood loop.

Related case studies