Resource
The resource area is the cross-product integration program: everything is a resource with opt-in capabilities, surfaced through one Azure-portal-like Resource Explorer at /resource-explorer. A sheet, a survey, a program, a todo list, a dashboard, an email, a webpage, and a flowchart are all the same thing to the resource layer — an identity row, a content blob, and a definition — differing only in which blades and commands their type declares.
The standards the area applies live in architecture: the layer model (cross-product layer model), the resource model (resource), datasets (dataset), and publishing (publishing). The pages in this area describe the product surface built on them.
Key concepts
- Resource — one Postgres identity row + one content blob in Azure Blob + one
ResourceDefinitionMapentry. Single-owner, auth-gated, onecontentVersionwrite path. - Capability — a cross-cutting mechanism a type opts into: Publishable (versioned snapshot + public
/view/[type]/[id]), DatasetProvider (serves columns + rows throughdataset.readDataset), Portable (import/export formats), FileAssets (hosted binary assets under{id}/files/…— see resource file assets). - Explorer — the Azure-portal-shaped shell: Home landing,
/resource-explorer/alllist, marketplace-style create flow, and a resource page composing blades. See resource explorer. - Blade — one panel of a resource page, addressed by route segment (
/resource-explorer/[id]/[[blade]]). Every resource has a built-in Overview; types add their own (Sheet: Data + Settings, Survey: Responses, Program: Setup + Status, TodoList: Items + Calendar) and editor-backed types render their editor inline in the Editor blade. - Dataset — the read contract that lets one resource consume another's data: a Dashboard visual binds to a
DatasetReference(dashboard data binding), an Email binds one for merge fields (email personalization), and a Program both binds one as its audience and serves one as its funnel status (program resource).
Feature pages
- Resource explorer — the shell: Home, list, create flow, resource page, blades, command bar
- Resource service menu — Home's drawer behind a hamburger: All, Favorites, Recent, Tags and the bin as sibling routes over one list surface
- List filters & views — the list workbench: filter pills, URL-synced state, bulk operations, column chooser, grouping, CSV export
- Summary view — the
/allList/Summary toggle: per-type count cards over a grouped count procedure - Resource page parity — labeled command bar with overflow, Refresh, Duplicate, a delete the bin undoes, save-conflict surface
- Share to esbabbler — Share command posting a published resource's public link into a room you pick
- Notifications bell — session-scoped operation-outcome toasts + the dock's notifications panel
- TodoList agent follow-ups — Claude Code sessions write the follow-ups they leave into the list and drain them until none is left, through the follow-ups plugin and the MCP endpoint
- TodoList due reminders — web-push when a TodoList item comes due, over the scheduled-job + push subsystems
- TodoList completion — a checkbox on every row, a collapsible Completed section, and delete from the row's context menu
- TodoList importance — a star on every row, and a Sort menu that orders the view but never the list
- TodoList manual order — open todos dragged or Alt+arrowed into the reader's own order
- TodoList print list — Export → Print, with the steps and notes as toggles and the list in the reader's sort
- TodoList recurrence — a dated todo repeats, and ticking it rolls it to its next due date
- TodoList quick add — an Add a todo field that adds on Enter, with search folded into a button
- TodoList steps — a flat checklist inside a todo, ticked in its dialog and counted on its row
- TodoList task rows — a title, one metadata line and the notes in full, in place of the Items table
- Global search — grouped as-you-type in the
Ctrl+Kcommand palette, keyboard chords, relevance-ranked results - Global search relevance —
pg_trgmtrigram index andsimilarity()ranking, so a typo still finds its resource - Favorites & recents — server-side stars and server-side opens, as Home tabs and as full list routes
- Resource tags — name:value pairs in Essentials, edited in place, filterable on
/all - Recycle bin — soft delete with restore, permanent purge, and a 30-day timer sweep
- Activity log — the per-resource audit trail blade, in Azure Table Storage
- Resource snapshots — published versions and revisions of the working copy in one version history panel, with preview, restore and undo
- Resource version store — every retained version as a content-addressed keyframe or delta, so a run of edits costs a compressed copy plus the edits rather than a copy per version
- Resource save state — one derived state in the blade toolbar saying whether the open resource's edits have reached the server, and when
- Delta content saves — a large document's save as a zstd delta against the bytes the server stores, falling back to a full save on any mismatch
- Shell cohesion — the shared chrome primitives (page header, breadcrumbs, empty/loading states, launcher)
- Breadcrumb trail — crumbs are the click path, the current page is the title, and a direct link shows no ancestor at all
- Sheet resource — CSV/JSON/XLSX files as resources with Data + Settings blades
- Create from file — drop a CSV/JSON/XLSX on the Sheet create form and land in a ready Data blade
- Sheet editor — the grid editor behind the Sheet resource's Data blade: inline editing, data cleaning, computed columns, statistics, clipboard
- Survey resource — SurveyJS authoring, public respondent page, responses dataset
- Program resource — the distribution orchestrator: audience + email + survey bindings, opaque participant tokens, funnel status
- Note resource — a rich-text document type on Tiptap: JSON at rest, publishable
generateHTMLread view - Blueprint resource — a parameterized manifest of resources: deploy one blueprint, get a fully wired set with all the right cross-references
- Blueprint capture — Save as blueprint on selected resources: contents captured, cross-resource ids rewritten to aliases automatically
- Survey response controls — the accepting-responses toggle and the closed state that keeps participant links alive
- Survey response modes — Anonymous or Identified identity, enforced at the write boundary
- Survey response summary — the Responses blade opens on one chart, range or answer list per question
- Survey response management — response detail, owner delete, response count on Overview
- Published view analytics — best-effort view counts on public reads for every publishable type
- Dashboard data binding — visuals bound to datasets with client aggregation and publish-time snapshots
- Dashboard duplicate visual — Duplicate on a tile's corner copies its chart settings and binding
- Dashboard chart interaction — the ApexCharts v6 investigation surface on visuals: linked highlighting, shareable view state, annotations
- Email personalization — merge fields, survey invite blocks, personalized HTML export
- Dataset row-cap warning — "showing N of M" wherever a dataset read hits the 1000-row cap
- Email preview text — the inbox line under the subject, written into the MJML as its
mj-preview - Email web view — Email is Publishable: save-time HTML capture,
/view/Email/[id]browser copy - Flowchart publish — Flowchart is Publishable: read-only VueFlow render at
/view/Flowchart/[id] - Resource file assets — the FileAssets capability: hosted binary assets + GrapesJS Asset Manager
- Storage quotas — per-user blob allowance held at SAS issuance and charged by Storage's own
BlobCreatedevent, with a usage bar in the explorer shell's header - Webpage survey invite blocks — published surveys as drag-in invite buttons in both GrapesJS editors
Open work is in the roadmap; the Azure-portal-parity designs it references live under proposals. Ideas we chose not to pursue are under deferred (with revisit triggers) and rejected. The grid editor keeps its own roadmap, deferred and rejected pages beside it, under sheet editor.
Shipped log
One line per program of work; the feature pages above carry the detail. The fact worth keeping at this level is what the whole program cost: one Azure Table for the activity blade, one Service Bus queue for reminders, one Event Grid subscription on a system topic that already existed, and a handful of Postgres migrations — no new Azure service at any point.
- Resource Explorer consolidation — every product became a resource behind one explorer: the
resourcesandresource_publicationstables, oneResourceAssetscontainer replacing six, thecreateResourceProceduresfactory, and every per-editor page, picker and hub deleted. - Capabilities — Publishable, DatasetProvider, Portable and FileAssets, each adopted by the types that declare them rather than rebuilt per type.
- Explorer surface — the list workbench, summary view, service menu, command-bar parity, global search and its trigram ranking, favorites, recents, tags, the recycle bin, activity log, and version history.
- Resource types — Sheet (renamed from File), Survey, Program, Note and Blueprint, plus publish parity for Email and Flowchart.
- Datasets — the read contract one resource consumes another through: dashboard visual binding, email merge fields, and the Program funnel status, with the row cap surfaced wherever a read hits it.
- TodoList to a todo product — Microsoft To Do's lean core over the TodoList: task rows, completion, quick add, importance, manual order, steps, print list and recurrence, each an optional field or a view so no stored list needed a backfill.
- TodoList agent follow-ups — Claude Code sessions capture the follow-ups they leave into the TodoList and drain them, over one MCP endpoint any procedure opts into and an API key table in
auth; no new Azure service and no model inside the app. - Resource services — storage quotas charged by Storage's own
BlobCreatedevent, TodoList due reminders on the scheduled-job stack, the notifications bell, and version history re-based onto content-addressed keyframes and deltas in a workspace package of its own.