Let external assistants create and configure Content databases

[3mdistal]

Problem

An external assistant connected to Content through the Model Context Protocol (MCP) can already edit database rows, but it can't set up the database those rows need. A request such as “Create a campaign tracker with Status and Publish date fields and a Ready drafts view” still requires someone to configure the table in Content first.

Approach

Expose the missing setup operations through Content's shared action surface. An assistant can choose an authorized space, create a database, configure ordinary fields and saved table views, then use the existing row actions to populate it. Returned links open the same database, view, or row in Content so a person can inspect and continue the work.

This covers ordinary stored fields and table presentation. It doesn't add source connections, joins, formulas, relations, rollups, destructive schema changes, or additional view types to the external setup workflow.

What changed

• Add discoverable setup actions for database creation, field configuration, saved table views, and recoverable Trash/restore. Discovery tells the assistant which space and database it can use and which fields are editable. A text field can be designated as the existing unique row key for subsequent create-or-update requests.
• Require current database revisions and a unique request key. Changes and their confirmation records are saved together, allowing an unchanged retry to return the original result without creating another database, field, or view. Partial updates preserve unrelated settings and stable field/option identities.
• Route ordinary UI creation, property edits, and shared view saves through the guarded actions. Serialize view saves so queued edits use the revisions returned by the preceding save. Preserve database membership and selected-view context in links. Restore system and older unscoped database saves through their existing frontend contract, including autosave and Save for everyone; ordinary databases keep revision checks.
• Keep mobile Info open during local property edits, contain its child editors within the modal focus boundary, and preserve layered Escape dismissal. Fix the reproduced first-title-edit conflict after page creation. Let open pages recover after an external Trash/restore cycle. Refresh Trash lists and active sidebar databases on non-page routes as well. Use the shared settings sheet to support Escape and restore keyboard focus.
• Apply one source ownership policy to table rows, preview/full-page property editors, and mutation actions. Explicitly local-owned writable mappings remain editable; source-owned, derived, and read-only mappings remain protected, including unmatched secondary-source rows. Preserve primary-source values. Source inspection returns scoped status and mappings without row payloads or private change details.
• Preserve complete, sanitized MCP results for opted-in actions when display text is shortened, and keep object-only union inputs available to the in-app assistant. Register core audit tools for statically registered app agents as well as the HTTP action surface.

Safety and operations

Every setup request checks the caller's access and exact target, including retries after permission changes. Stale revisions produce a conflict rather than overwriting newer work. Trash preserves records for restoration; this workflow doesn't permanently purge data.

Migration 91 adds a receipt table and unique index, preserving main's migration 90 database index and migration 89. The PR includes a core changeset and Content changelog entries. Reverting code won't undo databases or fields already created. Verification used local fixtures; no hosted mutation or deployment is claimed.

Verification

The cumulative local DB01–DB16 acceptance is complete. Authenticated SDK protocol tests cover setup/row/Trash/restore, concurrent retries, stale revisions, permission revocation, redaction, and rejected legacy inputs. Database suites pass on PGlite and PostgreSQL. Earlier builds and focused UI, route, lifecycle and compatibility suites retain their original evidence revisions.

The final source-policy repairs pass 127 focused tests, Content typecheck and all 71 guards. Static-agent audit registration passes 118 core tests and core typecheck; 30 product-impact tests pass. Independent technical reviews found no actionable findings. Test sets overlap and are not a combined total. The branch has incorporated main through 0474826. The merge replay passes setup, source, core-surface, editor, Content Files database, typecheck and guard checks. The incoming Content Files test fixture now uses BIGINT for organization timestamps, matching production. The final mobile Info repair passes 97 focused editor tests, Content typecheck and all 71 guards. Exact-diff review found no actionable findings. All required GitHub checks pass on c729d7b; all reported checks are terminal success, neutral or skipped.

Real browser checks cover desktop1280×720, compact768×720 and mobile390×844: fresh Personal-page creation/reload, returned database links, actual error/Retry/recovery, writable local fields and protected source fields in table/preview/full-page Info, and source-state distinctions. Separate MCP reads confirm UI saves. The normal in-app agent's raw audit output shows one attributable restore and a verification-only replay with the same receipt/revisions; mobile requery returns the same two events. After merging main, a fresh title/local-field/saved-view replay confirms separate MCP readback and reload persistence. Desktop and mobile Info saves pass; nested value-editor and Add-property Escape retain Info, and the next Escape closes it. Earlier schema/view/row polling, view links, settings focus, repeated Trash/restore and shared-save compatibility evidence remains applicable and separately dated.

All owned fixtures are recoverable in Trash. Independent reads show no active ordinary databases in the three fixture spaces and no active checked row/page fixtures. The original welcome Page and system configuration are preserved. Diagnostic network faults are cleared, viewport reset, QA tabs closed and owned runtime stopped.

Local HTTP checks use trusted loopback identity; separate SDK tests exercise authenticated identity and access changes. Hosted provider authorization, ingestion/join behavior and the earlier hosted New page root cause remain unverified. Raw tool output requires scrolling, long property labels truncate, and the existing mobile calendar day-number clipping remains documented. On narrow mobile view tabs, the scroll track can intercept a center click; the visible upper tab area and keyboard selection work. Motion is unverified. No deployment is claimed.

Review focus

Inspect whether retries preserve authorization, whether complete structured results retain the existing redaction boundary, and whether active database projections stay coherent after lifecycle changes. The reported missing createHash import is present on the current head.

Follow-ups

A separate proposed autosave investigation concerns reloading 60 ms after title blur, which can interrupt a pending save. That proposal hasn't been approved or implemented here.

content_product_impact:
  lane: contract_fulfillment
  features:
    - content.feature.durable-foundations
    - content.feature.data-that-keeps-itself-right
    - content.feature.see-your-information-your-way
  capabilities:
    - content.object.database
    - content.agent.action-parity
    - content.property.typed
    - content.view.query
  record_change: included
  proof:
    - templates/content/actions/database-setup-mcp.db.test.ts
    - templates/content/actions/database-setup.db.test.ts
    - templates/content/actions/database-property-view-setup.db.test.ts
    - templates/content/app/hooks/use-document-properties.test.ts
    - pnpm test:content-product-impact
  rationale: Deliver bounded ordinary database setup parity and update its evidence without claiming broader schema, view, or source contracts are complete.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes and found 4 potential issues 🔴

Review Details

Incremental Code Review Summary

The latest PR head adds the remaining lifecycle-refresh fix and continues the guarded Content database setup work across MCP actions, source/property handling, saved views, and integration coverage. The lifecycle-refresh issue from the prior review was verified fixed and its existing thread was resolved before this review.

This remains high risk because the PR changes authorization-sensitive data mutation paths and expands the MCP contract. Four independent balanced reviews inspected the complete 67-file diff. Most setup, access, receipt, and structured-result paths remain well-factored, but one production regression and several newly added test-fixture failures need attention:

• 🔴 HIGH: Writable local/source-mapped properties are now rejected unconditionally by set-document-property.
• 🟡 MEDIUM: New PGlite integration suites exceed Vitest's default beforeAll timeout, preventing the new coverage from running reliably.

A direct run of the three new setup suites also exited unsuccessfully during migration/setup rather than producing test results. Browser verification was attempted, but Chrome automation was unavailable while the dev server remained healthy.

🧪 Browser testing: Attempted after this review; all 17 planned UI cases were blocked because Chrome browser automation tools were unavailable in the executor environment.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
32919281	Triggered	JSON Web Token	1e497c7	packages/core/src/email-catalog/redact-body.spec.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}