@protobase/cli 0.67.3 → 0.67.4

package/dist/build/app-icons.js

@@ -35,7 +35,7 @@ const projectIcons = (projectDir) => ({
 	png: Object.keys(pngIcons).filter((icon) => existsSync(path.join(projectDir, pngIcons[icon].file)))
 });
 /**
-* Writes the app's icons into `publicDir`: the favicon, the project's or Protobase's (see `buildFavicon`), and the PNGs
+* Writes the app's icons into `publicDir`: the favicon, the project's or the neutral mark (see `buildFavicon`), and the PNGs
 * the project has, each checked to be its size. Says which are the project's own, which the server's manifest names.
 */
 const buildIcons = async ({ projectDir, publicDir }) => {

package/dist/build/favicon.js

@@ -5,12 +5,12 @@ import path from "node:path";
 import { copyFile } from "node:fs/promises";
 //#region src/build/favicon.ts
 const defaultFavicon = path.join(adminAppDir, "favicon.svg");
-/** The favicon the app shows for the project in `projectDir`: its protobase.favicon.svg, or Protobase's without one. */
+/** The favicon the app shows for the project in `projectDir`: its protobase.favicon.svg, or a neutral mark without one. */
 const projectFavicon = (projectDir) => {
 	const own = projectDir === void 0 ? void 0 : path.join(projectDir, faviconFile);
 	return own && existsSync(own) ? own : defaultFavicon;
 };
-/** Writes the project's favicon, or Protobase's when it has none, to `outFile`, so the app's link to it always resolves. */
+/** Writes the project's favicon, or the neutral mark when it has none, to `outFile`, so the app's link to it always resolves. */
 const buildFavicon = ({ projectDir, outFile }) => copyFile(projectFavicon(projectDir), outFile);
 //#endregion
 export { buildFavicon, faviconFile, projectFavicon };

package/dist/cli/package.js

@@ -1,4 +1,4 @@
 //#region package.json
-var version = "0.67.3";
+var version = "0.67.4";
 //#endregion
 export { version };

package/dist/doctor/run.js

@@ -52,7 +52,8 @@ const runDoctor = async (options, out) => {
 	out(`Checked ${builtIn.models.length > 0 ? `${counted} and ${builtIn.models.length} built-in ones` : counted}: ${errors} errors, ${issues.length - errors} warnings.\n`);
 	return {
 		errors,
-		warnings: issues.length - errors
+		warnings: issues.length - errors,
+		issues
 	};
 };
 //#endregion

package/dist/doctor/user-table-models.js

@@ -1,22 +1,29 @@
-import { userTableResources } from "@protobase/server/config-exports";
+import { ownedTableNames, userTableResources } from "@protobase/server/config-exports";
 //#region src/doctor/user-table-models.ts
 /**
-* The models of the tables users add, which doctor checks like the config's, and an error for each definition that
-* does not fit the database or whose name a resource in code has, as the server leaves those out.
+* The models of the tables users add, which doctor checks like the config's, an error for each definition that does
+* not fit the database, and a warning for each whose name a resource in code has, as the server leaves those out: one
+* that code owns, as `protobase eject` writes it, waits for `protobase migration` to delete its definition.
 */
 const userTableModels = async (db, codeModels) => {
 	const tables = await userTableResources(db);
 	const taken = new Set(codeModels.map((model) => model.name));
+	const owned = new Set(ownedTableNames(codeModels));
 	const built = tables.resources.map((source) => source.toModel());
+	const takenIssue = (name) => owned.has(name) ? {
+		severity: "warning",
+		resource: name,
+		message: "a resource in code owns this user table now; once that code has deployed, `protobase migration` writes the delete of its definition"
+	} : {
+		severity: "warning",
+		resource: name,
+		message: "a resource in code has the name of this user table, which is not served"
+	};
 	const issues = [...tables.problems.map((message) => ({
 		severity: "error",
 		resource: "user tables",
 		message
-	})), ...built.filter((model) => taken.has(model.name)).map((model) => ({
-		severity: "warning",
-		resource: model.name,
-		message: "a resource in code has the name of this user table, which is not served"
-	}))];
+	})), ...built.filter((model) => taken.has(model.name)).map((model) => takenIssue(model.name))];
 	return {
 		models: built.filter((model) => !taken.has(model.name)),
 		issues

package/dist/eject/eject-files.js

@@ -0,0 +1,73 @@
+import { camelCase } from "../infer/names.js";
+import { proposeField } from "../infer/proposal.js";
+import { renderDataFile } from "../scaffold/data-file.js";
+import { planResource } from "../scaffold/resource-plan.js";
+import { uiFields } from "../scaffold/ui-fields.js";
+import { renderUiFile } from "../scaffold/ui-file.js";
+import { maxTextLength } from "@protobase/server/config-exports";
+//#region src/eject/eject-files.ts
+const decisionOf = ({ table, definition, model }, column) => {
+	const proposal = {
+		...proposeField(table, column, {
+			table,
+			resourceNameOf: (_, name) => name
+		}),
+		name: column.name
+	};
+	const served = model.fields[column.name];
+	if (!served) return {
+		proposal,
+		ignored: true
+	};
+	const capped = definition.fields.some((field) => field.name === column.name && field.type === "text");
+	return {
+		proposal: {
+			...proposal,
+			filterable: served.filterable,
+			sortable: served.sortable,
+			...capped && { max: maxTextLength }
+		},
+		ignored: false
+	};
+};
+/**
+* The config/<name>/data.ts and ui.ts that serve a table users added as the server serves it from its definition, written
+* with scaffold's renderers: its resource of the same name over the same table, its fields, key, search and admins-only
+* access, then its view with the definition's names, title and field labels, and scaffold's list.
+*/
+const ejectFiles = (ejected) => {
+	const { table, definition, model } = ejected;
+	const decisions = table.columns.map((column) => decisionOf(ejected, column));
+	const plan = planResource(definition.name, table, decisions);
+	if (!plan) throw new Error(`${definition.name}: its table has no primary key`);
+	const data = renderDataFile({
+		...plan,
+		softDelete: void 0,
+		tenant: void 0,
+		search: model.search?.[0],
+		adminsOnly: true
+	});
+	const labels = {
+		singular: definition.singular_label,
+		plural: definition.plural_label,
+		...definition.title_field !== null && { title: definition.title_field },
+		fields: definition.fields.map((field) => ({
+			name: field.name,
+			label: field.label,
+			multiline: field.type === "long_text"
+		}))
+	};
+	const target = {
+		resource: definition.name,
+		identifier: camelCase(definition.name),
+		tableName: table.name,
+		fields: uiFields(table, void 0, decisions),
+		labels
+	};
+	return {
+		data,
+		ui: renderUiFile(target, ["names", "list"])
+	};
+};
+//#endregion
+export { ejectFiles };

package/dist/eject/read-ejected.js

@@ -0,0 +1,37 @@
+import { connect } from "../db/connect.js";
+import { introspect } from "../db/introspect.js";
+import { readOnlyDb } from "../db/read-only-db.js";
+import { readTableDdl } from "./table-ddl.js";
+import { userTableResources, userTablesSchema } from "@protobase/server/config-exports";
+//#region src/eject/read-ejected.ts
+const notServed = (name, problems) => problems.find((problem) => problem.startsWith(`The user table "${name}" `)) ?? `No table users added is named "${name}"`;
+/**
+* Each named table users added as the server serves it, with the constraints and indexes of its table, read from the
+* database at `url` in read-only sessions. A name the server serves no table of stops it, with why.
+*/
+const readEjected = async (url, names) => {
+	const sql = connect(url);
+	const db = readOnlyDb(url);
+	try {
+		const [relations, served] = await Promise.all([introspect(sql), userTableResources(db)]);
+		const tables = names.map((name) => {
+			const definition = served.definitions.find((each) => each.name === name);
+			if (!definition) throw new Error(notServed(name, served.problems));
+			return {
+				table: relations.find((each) => each.schema === userTablesSchema && each.name === name),
+				definition,
+				model: served.resources.map((resource) => resource.toModel()).find((each) => each.name === name)
+			};
+		});
+		const read = [];
+		for (const ejected of tables) read.push({
+			ejected,
+			ddl: await readTableDdl(sql, ejected.table)
+		});
+		return read;
+	} finally {
+		await Promise.all([sql.end(), db.destroy()]);
+	}
+};
+//#endregion
+export { readEjected };

package/dist/eject/register.js

@@ -0,0 +1,23 @@
+import { isConnectionString, resolveConnectionUrl } from "../db/connection-url.js";
+import { loadNearestEnvFile } from "../dev/env.js";
+import path from "node:path";
+//#region src/eject/register.ts
+const out = (text) => process.stdout.write(text);
+const registerEject = (program) => {
+	program.command("eject").description("Take tables users added over as code: write config/<table>/data.ts and ui.ts, and a migration that makes each table as it is").argument("<args...>", "connection string (default: DATABASE_URL from the environment or .env) followed by the names of the tables").option("--env <variable>", "read the connection string from this environment variable").option("--config <dir>", "config folder", "config").option("--dir <dir>", "migrations folder", "db/migrations").action(async (args, opts) => {
+		loadNearestEnvFile(process.cwd());
+		const [first, ...rest] = args;
+		const fromArgument = !opts.env && first !== void 0 && isConnectionString(first);
+		const url = resolveConnectionUrl(fromArgument ? first : void 0, opts.env);
+		const { runEject } = await import("./run.js");
+		await runEject({
+			url,
+			names: fromArgument ? rest : args,
+			configDir: path.resolve(opts.config),
+			migrationsDir: path.resolve(opts.dir),
+			projectDir: process.cwd()
+		}, out);
+	});
+};
+//#endregion
+export { registerEject };

package/dist/eject/run.js

@@ -0,0 +1,112 @@
+import { camelCase } from "../infer/names.js";
+import { readExistingResources } from "../scaffold/existing-config.js";
+import { ensureExports } from "../scaffold/index-file.js";
+import { viewName } from "../scaffold/ui-file.js";
+import { nextMigrationName } from "../auth/migration-file.js";
+import { runDoctor } from "../doctor/run.js";
+import { ejectFiles } from "./eject-files.js";
+import { readEjected } from "./read-ejected.js";
+import { tableMigration } from "./table-migration.js";
+import path from "node:path";
+import { mkdir, readFile, readdir, rm, writeFile } from "node:fs/promises";
+import { userTablesSchema } from "@protobase/server/config-exports";
+//#region src/eject/run.ts
+const readText = (file) => readFile(file, "utf8").catch((error) => {
+	if (error.code === "ENOENT") return void 0;
+	throw error;
+});
+const readNames = (dir) => readdir(dir).catch((error) => {
+	if (error.code === "ENOENT") return [];
+	throw error;
+});
+const migrationText = (tables, statements) => `-- The tables users added that \`protobase eject\` took over as code: ${tables.join(", ")}.\n-- Where they were added this changes nothing and moves no row; on an empty database it makes them, without their rows.\n\n${statements.join("\n\n")}\n`;
+const checkNames = async ({ names, configDir }) => {
+	if (names.length === 0) throw new Error("Name the tables to eject");
+	const twice = names.find((name, i) => names.indexOf(name) !== i);
+	if (twice) throw new Error(`"${twice}" is named twice`);
+	const existing = await readExistingResources(configDir);
+	for (const name of names) {
+		const owner = existing.find((resource) => resource.name === name || resource.table === `${userTablesSchema}.${name}`);
+		if (owner) throw new Error(`"${name}" is a resource in code already, in ${path.join(owner.dir, "data.ts")}`);
+	}
+};
+const configChanges = async (options, files) => {
+	const changes = [];
+	for (const { name, data, ui } of files) for (const [file, after] of [[path.join(options.configDir, name, "data.ts"), data], [path.join(options.configDir, name, "ui.ts"), ui]]) {
+		if (await readText(file) !== void 0) throw new Error(`${file} exists already`);
+		changes.push({
+			path: file,
+			after
+		});
+	}
+	const index = path.join(options.configDir, "index.ts");
+	const before = await readText(index);
+	const registrations = files.flatMap(({ name }) => [{
+		from: `./${name}/data`,
+		names: [camelCase(name)]
+	}, {
+		from: `./${name}/ui`,
+		names: [viewName(camelCase(name))]
+	}]);
+	changes.push({
+		path: index,
+		...before !== void 0 && { before },
+		after: ensureExports(before ?? "", registrations)
+	});
+	return changes;
+};
+const write = async ({ path: file, before, after }) => {
+	const made = await mkdir(path.dirname(file), { recursive: true });
+	await writeFile(file, after, { flag: before === void 0 ? "wx" : "w" });
+	return made;
+};
+const rollBack = async (changes, folders) => {
+	for (const { path: file, before } of changes) if (before === void 0) await rm(file, { force: true });
+	else await writeFile(file, before);
+	for (const folder of folders.reverse()) await rm(folder, {
+		recursive: true,
+		force: true
+	});
+};
+/**
+* Takes tables users added over as code: writes each one's config/<name>/data.ts and ui.ts, exports them from
+* config/index.ts, and writes one migration that makes the tables as they are, then runs doctor on the config. When
+* doctor finds an error in an ejected resource, or cannot run, every file is put back as it was and it stops. It only
+* reads the database.
+*/
+const runEject = async (options, out) => {
+	await checkNames(options);
+	const tables = await readEjected(options.url, options.names);
+	const config = await configChanges(options, tables.map(({ ejected }) => ({
+		name: ejected.definition.name,
+		...ejectFiles(ejected)
+	})));
+	const migration = path.join(options.migrationsDir, nextMigrationName(await readNames(options.migrationsDir), `eject_${options.names.join("_")}`));
+	const statements = tables.flatMap(({ ejected, ddl }) => tableMigration(ejected.table, ddl));
+	const changes = [...config, {
+		path: migration,
+		after: migrationText(options.names.map((name) => `${userTablesSchema}.${name}`), statements)
+	}];
+	const folders = [];
+	for (const change of changes) {
+		const made = await write(change);
+		if (made) folders.push(made);
+	}
+	const shown = (file) => path.relative(options.projectDir, file);
+	for (const change of changes) out(`${change.before === void 0 ? "created" : "updated"} ${shown(change.path)}\n`);
+	const errors = (await runDoctor({
+		url: options.url,
+		configDir: options.configDir,
+		projectDir: options.projectDir
+	}, out).catch(async (error) => {
+		await rollBack(changes, folders);
+		throw error;
+	})).issues.filter((issue) => issue.severity === "error" && options.names.includes(issue.resource));
+	if (errors.length > 0) {
+		await rollBack(changes, folders);
+		throw new Error(`doctor found ${errors.length} error${errors.length === 1 ? "" : "s"} in the ejected ${errors.length === 1 ? "resource" : "resources"}, so every file is as it was`);
+	}
+	out(`\nDeploy this soon: until it serves, the admin app still adds fields to ${options.names.join(", ")}. Once it has deployed, \`protobase migration\` writes the delete of ${options.names.length === 1 ? "its definition" : "their definitions"}.\n`);
+};
+//#endregion
+export { runEject };

package/dist/eject/table-ddl.js

@@ -0,0 +1,17 @@
+//#region src/eject/table-ddl.ts
+/** The constraints and indexes of `table`, read from the catalogue; the primary key first, the rest by name. */
+const readTableDdl = async (sql, table) => {
+	const constraints = await sql`
+    select c.conname as name, pg_get_constraintdef(c.oid) as definition from pg_constraint c
+    where c.conrelid = format('%I.%I', ${table.schema}::text, ${table.name}::text)::regclass and c.contype <> 'n' order by c.contype <> 'p', c.conname`;
+	const indexes = await sql`
+    select pg_get_indexdef(i.indexrelid) as definition from pg_index i join pg_class ic on ic.oid = i.indexrelid
+    where i.indrelid = format('%I.%I', ${table.schema}::text, ${table.name}::text)::regclass and not exists (select from pg_constraint c where c.conindid = i.indexrelid and c.conrelid = i.indrelid)
+    order by ic.relname`;
+	return {
+		constraints: [...constraints],
+		indexes: indexes.map((index) => index.definition)
+	};
+};
+//#endregion
+export { readTableDdl };

package/dist/eject/table-migration.js

@@ -0,0 +1,32 @@
+import { tableKey } from "../db/model.js";
+//#region src/eject/table-migration.ts
+const ident = (name) => `"${name.replaceAll("\"", "\"\"")}"`;
+const qualified = (table) => `${ident(table.schema)}.${ident(table.name)}`;
+const identity = (column) => column.identityAlways ? " generated always as identity" : " generated by default as identity";
+const columnSql = (table, column) => {
+	if (column.generated) throw new Error(`${tableKey(table)}.${column.name} is a generated column, which eject does not write: Not implemented`);
+	const kept = column.identity ? identity(column) : `${column.defaultExpr === void 0 ? "" : ` default ${column.defaultExpr}`}${column.notNull ? " not null" : ""}`;
+	return `  ${ident(column.name)} ${column.formatted}${kept}`;
+};
+const ifNotExists = (definition) => {
+	const statement = /^CREATE (UNIQUE )?INDEX ("(?:[^"]|"")*"|\S+) ON /;
+	if (!statement.test(definition)) throw new Error(`Unexpected index definition: ${definition}`);
+	return definition.replace(statement, (_, unique, name) => `create ${unique ? "unique " : ""}index if not exists ${name} on `);
+};
+const trigramIndex = /\b(gin|gist)_trgm_ops\b/;
+/**
+* The statements that make `table` as the catalogue has it, each a no-op where it is already there: its schema, the
+* pg_trgm extension when an index needs it, the table with its columns and constraints, then its indexes. On the
+* database it was read from they change nothing; on an empty one they make the table again, without its rows.
+*/
+const tableMigration = (table, ddl) => {
+	const body = [...table.columns.map((column) => columnSql(table, column)), ...ddl.constraints.map(({ name, definition }) => `  constraint ${ident(name)} ${definition}`)];
+	return [
+		`create schema if not exists ${ident(table.schema)}`,
+		...ddl.indexes.some((index) => trigramIndex.test(index)) ? ["create extension if not exists pg_trgm"] : [],
+		`create table if not exists ${qualified(table)} (\n${body.join(",\n")}\n)`,
+		...ddl.indexes.map(ifNotExists)
+	].map((statement) => `${statement};`);
+};
+//#endregion
+export { tableMigration };

package/dist/infer/proposal.d.ts

@@ -10,6 +10,7 @@ export type Proposal = {
   precision?: number;
   scale?: number;
   enumValues?: string[];
+  max?: number;
   relation?: {
     resource: string;
     columns?: string[];

package/dist/infer/render-field.js

@@ -14,6 +14,7 @@ const base = (p) => {
 };
 const renderField = (p) => [
 	base(p),
+	p.max !== void 0 && `.max(${p.max})`,
 	p.optional && ".optional()",
 	p.defaultValue !== void 0 && `.default(${literal(p.defaultValue)})`,
 	p.dbDefault && ".dbDefault()",

package/dist/main.js

@@ -5,6 +5,7 @@ import { loadNearestEnvFile } from "./dev/env.js";
 import { placeholderSecretWarning } from "./project/placeholder-secret.js";
 import { registerOrganizations } from "./organizations/register.js";
 import { registerFiles } from "./files/register.js";
+import { registerEject } from "./eject/register.js";
 import { registerEncryption } from "./encryption/register.js";
 import { registerMigration } from "./migration/register.js";
 import { registerMobile } from "./mobile/register.js";
@@ -177,6 +178,7 @@ registerOrganizations(program);
 registerToken(program);
 registerAuth(program);
 registerMigration(program);
+registerEject(program);
 registerFiles(program);
 registerEncryption(program);
 registerSkill(program);

package/dist/migration/parts.js

@@ -1,5 +1,5 @@
 import { authMigrationTitle } from "../auth/migration-file.js";
-import { authSchemaMigration, callsMigration, changesMigration, channelSendsMigration, commentsMigration, computedMigration, isCaptured, jobsSchemaMigration, notificationsMigration, queryRunnerMigration, realtimeRelayMigration, relayed, sqlSends, statusMigration, userTablesMigration, webhooksMigration } from "@protobase/server";
+import { authSchemaMigration, callsMigration, changesMigration, channelSendsMigration, commentsMigration, computedMigration, isCaptured, jobsSchemaMigration, notificationsMigration, ownedDefinitionsMigration, queryRunnerMigration, realtimeRelayMigration, relayed, sqlSends, statusMigration, userTablesMigration, webhooksMigration } from "@protobase/server";
 //#region src/migration/parts.ts
 /** Every feature the project's config enables, in the order their files are written. */
 const migrationParts = (project) => {
@@ -66,6 +66,11 @@ const migrationParts = (project) => {
 			title: "The schemas of the tables users add and of their definitions, and pg_trgm",
 			sql: () => userTablesMigration(project.db)
 		}] : [],
+		...project.userTables ? [{
+			name: "owned_definitions",
+			title: "The delete of the definitions of user tables that resources in code own now",
+			sql: () => ownedDefinitionsMigration(project.db, project.models)
+		}] : [],
 		...sqlSends(project.realtime) ? [{
 			name: "channel_sends",
 			title: "SQL's broadcasts to the record channels, channels.send()",

package/dist/project/favicon-link.js

@@ -10,7 +10,7 @@ import { pngIcons } from "@protobase/schema/png-icons";
 * Links the project's favicon at `/protobase.favicon.svg` in the app's page, and its Apple touch icon at
 * `/protobase.apple-touch-icon.png`, which Safari takes for the home screen as it takes no SVG. A bundle always has
 * the favicon (see `buildFavicon`) and the touch icon when the project has one (see `buildIcons`); without it Safari
-* shows a picture of the page instead. The dev server answers them from the project's files, the favicon Protobase's
+* shows a picture of the page instead. The dev server answers them from the project's files, the favicon the neutral mark
 * without one, the project's other PNG icons the same way, and `/favicon.ico` as a bundle's server does (see `faviconIcoFile`).
 */
 const faviconLink = (projectDir) => {

package/dist/scaffold/data-file.js

@@ -10,6 +10,11 @@ const docComment = (plan) => {
 	const unique = plan.unique.map((columns) => `(${columns.join(", ")})`).join(", ");
 	return `/** ${tableKey(plan.table)}${unique ? `. Unique: ${unique}` : ""} */\n`;
 };
+const adminsRule = [
+	`import { f, resource, type AccessContext } from '@protobase/schema'`,
+	"",
+	`const admins = ({ user }: AccessContext) => user?.roles?.includes('admin') ?? false`
+];
 const renderDataFile = (plan) => {
 	const properties = plan.decisions.map((d) => `    ${propertyText(d)},`).join("\n");
 	const tail = [
@@ -17,10 +22,12 @@ const renderDataFile = (plan) => {
 		plan.softDelete && `  .softDelete((r) => r.${plan.softDelete})`,
 		plan.tenant && `  .tenant((r) => r.${plan.tenant})`,
 		plan.search && `  .search((r) => [r.${plan.search}])`,
-		plan.live && "  .live()"
+		plan.live && "  .live()",
+		plan.adminsOnly && "  .explicitGrants()",
+		plan.adminsOnly && "  .access({ list: admins, read: admins, create: admins, update: admins, delete: admins })"
 	].filter(Boolean);
 	return [
-		`import { f, resource } from '@protobase/schema'`,
+		...plan.adminsOnly ? adminsRule : [`import { f, resource } from '@protobase/schema'`],
 		"",
 		`${docComment(plan)}export const ${camelCase(plan.name)} = resource('${plan.name}')`,
 		`  .table('${tableKey(plan.table)}')`,

package/dist/scaffold/ui-file.js

@@ -1,6 +1,7 @@
 import { humanize, humanizeSingular } from "../infer/names.js";
 import { parseSource } from "./project.js";
 import { methodCalls } from "./existing-config.js";
+import { quote } from "../infer/render-field.js";
 import { Node, SyntaxKind } from "ts-morph";
 //#region src/scaffold/ui-file.ts
 const auditField = /^(created|updated)(At|On|_at|_on)$/;
@@ -48,19 +49,27 @@ const listSort = (fields) => {
 	return (dates.find((f) => createdField.test(f.name)) ?? dates[0])?.name;
 };
 const viewName = (identifier) => `${identifier}View`;
+const namesText = (singular, plural) => `.names({ singular: ${quote(singular)}, plural: ${quote(plural)} })`;
 const sectionText = {
-	names: (t) => `.names({ singular: '${humanizeSingular(t.tableName)}', plural: '${humanize(t.tableName)}' })`,
+	names: (t) => t.labels ? namesText(t.labels.singular, t.labels.plural) : namesText(humanizeSingular(t.tableName), humanize(t.tableName)),
 	list: (t) => {
 		const sort = listSort(t.fields);
 		return `.list((r) => ({ columns: [${listColumns(t.fields).map((n) => `r.${n}`).join(", ")}]${sort ? `, sort: [[r.${sort}, 'desc']]` : ""} }))`;
 	}
 };
+const fieldLabel = ({ name, label, multiline }) => `    ${name}: r.${name}.label(${quote(label)})${multiline ? ".multiline()" : ""},`;
+const labelLines = ({ title, fields }) => [...title ? [`  .title((r) => r.${title})`] : [], ...fields.length > 0 ? [
+	"  .fields((r) => ({",
+	...fields.map(fieldLabel),
+	"  }))"
+] : []];
 const lines = (sections, target) => sections.map((s) => `  ${sectionText[s](target)}`);
 const renderUiFile = (target, sections) => [
 	`import { view } from '@protobase/schema'`,
 	`import type { ${target.identifier} } from './data'`,
 	"",
 	`export const ${viewName(target.identifier)} = view<typeof ${target.identifier}>('${target.resource}')`,
+	...target.labels ? labelLines(target.labels) : [],
 	...lines(sections, target),
 	""
 ].join("\n");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@protobase/cli",
-  "version": "0.67.3",
+  "version": "0.67.4",
   "description": "The protobase command: scaffold, doctor, dev, build and serve a Protobase project.",
   "license": "Apache-2.0",
   "repository": {
@@ -43,12 +43,12 @@
   "dependencies": {
     "@better-auth/core": "^1.7.12",
     "@hono/node-server": "^2.1.3",
-    "@protobase/config": "0.67.3",
-    "@protobase/layout": "0.67.3",
-    "@protobase/query": "0.67.3",
-    "@protobase/schema": "0.67.3",
-    "@protobase/server": "0.67.3",
-    "@protobase/ui": "0.67.3",
+    "@protobase/config": "0.67.4",
+    "@protobase/layout": "0.67.4",
+    "@protobase/query": "0.67.4",
+    "@protobase/schema": "0.67.4",
+    "@protobase/server": "0.67.4",
+    "@protobase/ui": "0.67.4",
     "@react-email/render": "^2.1.0",
     "@scalar/hono-api-reference": "^0.12.10",
     "@sentry/vite-plugin": "^11.10.0",

package/skills/protobase/references/features/look-and-language.md

@@ -6,7 +6,8 @@ The app's colours, name, icon, language and installation.
 
 - [Theme](../reference/theme.md): One CSS file sets the app's colours, corners and fonts for light and dark, and keeps working on every release.
 - [Dark mode](../reference/theme.md#light-dark-or-the-system): Each user picks light, dark or the system setting.
-- [App name, icon and colours](../reference/app-identity.md): The app's own name, icon and colours in the sidebar, browser tabs, `/favicon.ico`, home-screen icon and mail.
+- [App name, icon and colours](../reference/app-identity.md): The app's own name, icon and colours in the sidebar, sign-in page, browser tabs, API docs, `/favicon.ico`, home-screen icon and mail; an app without an icon of its own shows a neutral mark rather than Protobase's.
+- [Runs on Protobase note](../reference/app-identity.md#runs-on-protobase-note): A host can end the sign-in page on a small "Runs on Protobase" line by setting `PROTOBASE_RUNS_ON_NOTE=true`; without it there is no note.
 - [Logo and favicon](../reference/theme.md#logo-and-favicon): Your own favicon or logo replaces Protobase's.
 - [Named icons](../reference/layouts.md#named-actions): Actions, key facts and card meta show an icon picked by name from a set, such as `play`, `bed` or `cpu`.
 - [English and Dutch](../reference/languages.md): The built-in screens come in English and Dutch, with numbers and dates written to match.

package/skills/protobase/references/features/start-a-project.md

@@ -4,7 +4,7 @@
 
 Start a new app, or an admin over an existing Postgres database, and keep the config in step with it.
 
-- [Project starter](../getting-started.md#start-an-app): `npm create protobase` (also `bun create` and `pnpm create`) starts a new app from the scratch, ERP or real estate preset, with its own Postgres in Docker for development, and prints the next steps. Each preset has an `AGENTS.md` with rules for coding agents.
+- [Project starter](../getting-started.md#start-an-app): `npm create protobase` (also `bun create` and `pnpm create`) starts a new app from the scratch, ERP, property portal or real estate preset, with its own Postgres in Docker for development, and prints the next steps. Each preset has an `AGENTS.md` with rules for coding agents.
 - [Start on an existing database](../getting-started.md#on-an-existing-database): `npm create protobase <database-url>` makes a project on a Postgres database you already have and asks which of its tables become resources, only reading the database.
 - [Example apps](../getting-started.md#run-the-erp-example): Seeded example apps on Postgres: an ERP, real estate property management and a public property portal.
 - [One config](../reference/config.md): The whole app is one object of data in `protobase.config.ts`, typed with `defineConfig`, with a sensible default for every key.

package/skills/protobase/references/features/user-tables.md

@@ -6,3 +6,4 @@ Tables an app's users add from the admin UI, by hand or from a file, and how a d
 
 - [Tables defined in the database](../reference/user-tables.md#tables-defined-in-the-database) (beta): An app can keep tables its users add in its own database, beside the resources in its code. Each one is served like any other resource, at its own address with its list, record page, search and API. Every server process serves a new table within a second of it being added.
 - [Adding tables and fields](../reference/user-tables.md#adding-tables-and-fields) (beta): Someone with the right capability creates a table with its fields, or adds a field to it, through the app's API. It is created in the database at once, with an index for every field but JSON so its list can be filtered by it, and sorted by it unless it is long text, and only admins can see it until access is widened.
+- [Taking a table over as code](../reference/cli.md#eject) (beta): `protobase eject` turns a table someone added in the admin app into ordinary config and a migration in the project, so a developer can customise it like any other resource. Its records stay where they are.

package/skills/protobase/references/getting-started.md

@@ -10,7 +10,7 @@ An app's own React code, its components, field types and actions, is a [plugin](
 
 ## Start an app
 
-`npm create protobase my-app` asks which preset to start from, scratch (the default), the ERP or real estate, writes the project into `my-app`, with the `@protobase` packages in `devDependencies` at the caret range of the latest release, so it is [bundled](reference/versioning.md#bundled-and-locked-projects): dev, the build and its scripts run the CLI's own copies, and a newer CLI in that range updates it with no change to its files. It prints the next steps. Without a folder it asks for one too. `--preset <name>` picks the preset without asking; without a terminal it takes scratch. `bun create protobase` and `pnpm create protobase` do the same, and take `--preset` without the `--` that npm needs. It needs Node 22.12 or later. Each preset has an `AGENTS.md` with the rules for a coding agent that changes the app, such as a new migration file for every schema change.
+`npm create protobase my-app` asks which preset to start from, scratch (the default), the ERP, the property portal or real estate, writes the project into `my-app`, with the `@protobase` packages in `devDependencies` at the caret range of the latest release, so it is [bundled](reference/versioning.md#bundled-and-locked-projects): dev, the build and its scripts run the CLI's own copies, and a newer CLI in that range updates it with no change to its files. It prints the next steps. Without a folder it asks for one too. `--preset <name>` picks the preset without asking; without a terminal it takes scratch. `bun create protobase` and `pnpm create protobase` do the same, and take `--preset` without the `--` that npm needs. It needs Node 22.12 or later. Each preset has an `AGENTS.md` with the rules for a coding agent that changes the app, such as a new migration file for every schema change.
 
 ```sh
 npm create protobase my-app

package/skills/protobase/references/reference/app-identity.md

@@ -2,14 +2,14 @@
 
 # App identity
 
-The app's name, icon and colours, which its sidebar logo, browser tabs, home-screen icon, web manifest and mail all follow.
+The app's name, icon and colours, which its sidebar logo, sign-in page, browser tabs, API docs, home-screen icon, web manifest and mail all follow.
 
-An app looks like its own everywhere from three things in its project: its name, its icon and its colours. The sidebar's logo, the browser tab, the icon on a phone's home screen, the [installed app](installable-app.md) and the auth mail all follow them, with no component to write.
+An app looks like its own everywhere from three things in its project: its name, its icon and its colours. The sidebar's logo, the sign-in page, the browser tab, the API docs, the icon on a phone's home screen, the [installed app](installable-app.md) and the auth mail all follow them, with no component to write.
 
 | What | Where | Used by |
 | --- | --- | --- |
-| Name | `name` in `protobase.config.ts` ([config](config.md)), overridden at run time by `PROTOBASE_APP_NAME` | the sidebar's logo, the end of every tab title, the installed app's name, the [mobile app](../guides/mobile-app.md)'s name on the phone, passkey and authenticator prompts, auth mail and its sender's name |
-| Icon | `protobase.favicon.svg` at the project's root | the browser tab, `/favicon.ico`, the sidebar's logo, the installed app's icon, the [MCP endpoint](mcp.md#the-apps-icon)'s icon in AI clients; the [mobile app](../guides/mobile-app.md) shows Protobase's icon instead |
+| Name | `name` in `protobase.config.ts` ([config](config.md)), overridden at run time by `PROTOBASE_APP_NAME` | the sidebar's logo, the sign-in page's title ("Sign in to Acme Admin"), the end of every tab title, the title of the [API docs](api.md), the installed app's name, the [mobile app](../guides/mobile-app.md)'s name on the phone, passkey and authenticator prompts, auth mail and its sender's name |
+| Icon | `protobase.favicon.svg` at the project's root | the browser tab, `/favicon.ico`, the sidebar's logo, the sign-in page, the installed app's icon, the [MCP endpoint](mcp.md#the-apps-icon)'s icon in AI clients; the [mobile app](../guides/mobile-app.md) shows Protobase's icon instead |
 | Raster icons | optional PNGs beside the SVG, below | the iPhone home screen and Android launchers, which take no SVG |
 | Colours | `themeColor` and `backgroundColor` in `protobase.config.ts` | the installed app's title bar and its start screen |
 
@@ -28,6 +28,8 @@ export default defineConfig({
 
 `name` names the app; `PROTOBASE_APP_NAME`, when a deployment sets it, overrides it, so a deployment can rename an app without a new build. Without either the app is called `Protobase`.
 
+The app's name titles the sign-in page, such as "Sign in to Acme Admin", the browser tab and the API docs, and the page shown before the app has users speaks of the app rather than of Protobase. An app with a name of its own but no icon shows its initial where the icon would be, in the sidebar and on the sign-in page, and the neutral mark below in the tab and as the installed app's icon.
+
 ## The icons
 
 `protobase.favicon.svg` is the one source of the app's icon: the tab shows it, the [web manifest](installable-app.md#the-manifest) names it, and with it the sidebar's logo draws it in place of Protobase's mark, beside the app's name. A project's own [`shell.logo`](custom-components.md#shell-slots) still wins.
@@ -41,7 +43,7 @@ Some platforms take no SVG, so a project may put PNGs of the same icon beside it
 | `protobase.icon-512.png` | 512 × 512 | the web manifest, for Android's install screens |
 | `protobase.icon-maskable.png` | 512 × 512 | the web manifest's maskable icon, which Android crops to its own shape: keep the mark within the middle 80% |
 
-The app answers `/favicon.ico`, which browsers and favicon services ask for when they have not read the page, with its icon: the 192 pixel PNG, else the touch icon, else the 512 pixel PNG, else the SVG, each with its own content type. Without a favicon of its own the app answers Protobase's.
+The app answers `/favicon.ico`, which browsers and favicon services ask for when they have not read the page, with its icon: the 192 pixel PNG, else the touch icon, else the 512 pixel PNG, else the SVG, each with its own content type. Without a favicon of its own the app answers a neutral mark, a plain rounded square in no brand's colours, which the tab and the installed app show too.
 
 Each is optional, and none is made from the SVG: without the touch icon an iPhone's home screen shows a picture of the page. `protobase build` copies the ones the project has to the bundle's `public/`, and fails on a file that is no PNG or not its size; `protobase dev` serves them from the project's root.
 
@@ -53,3 +55,9 @@ Each takes any CSS colour, and the web manifest carries the ones set:
 - `backgroundColor`: the screen the installed app shows while it starts (`background_color`).
 
 The app's own colours, its buttons and surfaces, are the [theme](theme.md)'s.
+
+## Runs on Protobase note
+
+A host can have the sign-in page end on one small line, "Runs on Protobase", below the sign-in card, which links to protobase.net. It is plain, muted text in the app's own font, and the note shows on the sign-in page only: not in dialogs, and not inside the app after signing in.
+
+The host turns it on with `PROTOBASE_RUNS_ON_NOTE=true` where the app runs; without it, as self-hosted apps have it by default, there is no note. It is no option of `protobase.config.ts`, so it is the host's to set. The variable takes only `true` or `false`; any other value stops the app at startup, with an error naming the variable.

package/skills/protobase/references/reference/auth.md

@@ -102,7 +102,7 @@ The store's migrations then make nothing of the user table, which a migration of
 - Cookies are `SameSite=Lax`, and `Secure` when the app's `url` is https. When it is http with a port, their names carry it (`better-auth-5173.session_token`), because a browser shares cookies across the ports of a host: two apps on `localhost` then keep their own sign-ins.
 - Sign-in is rate limited (5 password attempts per minute and client by default, `signInPerMinute`, which also limits [sign-up](#open-sign-up) requests; 3 per minute for emailed codes); [Client addresses](#client-addresses) says how a client is known.
 - New passwords need at least 12 characters.
-- `name`, at the config's top level, is the app's name: authenticator apps and passkey prompts show it, the admin app's sidebar shows it at the top beside the app's [icon](app-identity.md#the-icons), else Protobase's mark (Protobase's wordmark when it is `Protobase`), every browser tab of the admin app ends its title with it, the [installed app](installable-app.md) is called by it, the [auth emails](email.md#protobases-own-mail) name the app with it, and the platform's mailer sends them as it (the sender's display name). `PROTOBASE_APP_NAME`, when set, overrides it; without either it is `Protobase`, then without a display name. See [App identity](app-identity.md).
+- `name`, at the config's top level, is the app's name: authenticator apps and passkey prompts show it, the admin app's sidebar shows it at the top beside the app's [icon](app-identity.md#the-icons), else its initial (Protobase's mark and wordmark when it is `Protobase`), the sign-in page's title names it, every browser tab of the admin app ends its title with it, the [installed app](installable-app.md) is called by it, the [auth emails](email.md#protobases-own-mail) name the app with it, and the platform's mailer sends them as it (the sender's display name). `PROTOBASE_APP_NAME`, when set, overrides it; without either it is `Protobase`, then without a display name. See [App identity](app-identity.md).
 
 ### Hooks
 

package/skills/protobase/references/reference/calls.md

@@ -117,11 +117,12 @@ await call.publish({ camera: media.getVideoTracks()[0], microphone: media.getAud
 
 | | |
 | --- | --- |
-| `publish(tracks, { simulcast })` | Sends tracks under their sources; rejects when the member may not. With `simulcast` and LiveKit, video goes in three sizes. |
+| `publish(tracks, { simulcast })` | Sends tracks under their sources; rejects with `PublishRefused`, exported beside `joinCall`, when the member may not. With `simulcast` and LiveKit, video goes in three sizes. |
 | `unpublish(source)` | Stops sending the source; the track itself goes on until the page stops it. |
 | `mute(source, muted)` | Mutes or unmutes a sent track; the others see `muted` on it. |
 | `view(sids, { width, height })` | With LiveKit: how large the page shows remote video, so it receives the size that fits; `'hidden'` receives none. |
 | `restartIce()` | New network paths, such as after a network change; a failed connection restarts by itself. |
+| `connections()` | How each of the member's connections fares now, to each other member peer-to-peer or to the media server with LiveKit: `{ member?, state, roundTripMs?, lostRatio? }`, the round trip and the share of received media lost once connected. |
 | `leave()` | Leaves the call. |
 
 `call.id` is the call, as the record's calls list it and `calls.remove` takes it. `onSpeakers` gets who speaks how loudly, and `onUnpublished` a source the media server stopped, such as after the member lost the right to send.

package/skills/protobase/references/reference/cli.md

@@ -130,6 +130,30 @@ Imports `config/index.ts` and the views of `config/*/ui.ts`, as the config modul
 
 Exit code is 1 when there are errors. Run it after the project's migrations and before a new version serves, as a platform's deploy does: a read it fails is one the API would refuse once the version runs. `protobase build` needs no database, so the indexes are doctor's to check.
 
+## `eject`
+
+:::caution[Beta]
+A table is taken over from the command line alone, keeps its name and stays in `user_tables`.
+:::
+
+```sh
+protobase eject [connection string | --env VAR] <table>... [--config <dir>] [--dir db/migrations]
+```
+
+Takes [tables users added](user-tables.md) over as code. The URL comes as for [`scaffold`](#scaffold). For each table named, as its definition names it, it writes `config/<table>/data.ts` and `config/<table>/ui.ts` with scaffold's renderers, exports them from `config/index.ts`, and writes one migration in `--dir`, `NNN_eject_<tables>.sql`. It only reads the database.
+
+- **`data.ts`** is a resource of the same name over `user_tables.<table>`, where the table stays: the fields of the definition as the server serves them, filterable, sortable and searched where the table's indexes serve them, a text field at most 500 characters, and every operation the admins' alone, with `.explicitGrants()`. A column the definition has no field for is written as `field: null`.
+- **`ui.ts`** has the definition's singular and plural label, its title field, each field's label, a long text field multiline, and the list `scaffold --ui` writes.
+- **The migration** makes each table as the catalogue has it: `create schema if not exists`, `create extension if not exists pg_trgm` when an index needs it, `create table if not exists` with the columns and constraints, and `create index if not exists` for each index, by its name. On the database the table is in it changes nothing and moves no row; on an empty one it makes the same table.
+
+Then it runs [`doctor`](#doctor) on the config. When doctor reports an error in an ejected resource, or cannot load the config, every file is put back as it was and the command fails. It refuses a name no definition the server serves has, saying why the server leaves it out, and one a resource in `config/` has, or whose table one reads, already.
+
+```sh
+protobase eject notes            # config/notes/data.ts, config/notes/ui.ts, db/migrations/NNN_eject_notes.sql
+```
+
+Deploy the change soon: until it serves, the admin app still adds fields to the table, which the new config does not have. Once it has deployed, [`migration`](#migration) writes the delete of the definition (see [Taking a table over as code](user-tables.md#taking-a-table-over-as-code)).
+
 ## `dev`
 
 ```sh
@@ -151,7 +175,7 @@ One port, two processes: Vite serves the admin app from `@protobase/ui`'s `src/a
 - **Tunnels and other hosts:** Vite only answers `localhost` by default. `--allowed-hosts .trycloudflare.com,app.example.com` adds Host headers (a leading dot matches all subdomains). The API's WebSockets, such as an [API function](../guides/api-functions.md#websockets)'s, pass the same check: an upgrade with another Host header is refused with `403`. Hot reload needs no extra setting: the Vite client takes protocol, host and port from the page, so behind an HTTPS tunnel it connects over `wss` on 443 as long as the tunnel forwards WebSockets.
 - **Project discovery**, by convention: `config/index.ts` exports the resources (and views), and every `config/*/ui.ts` export that is not already exported by the index is added as a view. Each `functions/<name>.ts` (or `functions/<name>/index.ts`) is an [API function](../guides/api-functions.md) at `/api/functions/<name>`. `protobase.config.ts` (or `protobase.config.json`) in the project root describes the rest as data, and the jobs, hooks and other code it names are found by their paths; see [protobase.config.ts](config.md). Without it, the app runs on the defaults.
 - **Project UI:** the app imports `protobase.ui.tsx` from the project root, with hot reload, when it exists (see [Custom components](custom-components.md)): the same contract as the plugin `protobase build` makes of it, built into the dev page instead. Layout files are checked as they load, as `protobase build` checks them.
-- **Theme:** the page links `/protobase.theme.css`, which the dev server answers from the project's [theme](theme.md), checked as the build checks it, on every request, so an edit shows on the next reload. It links `/protobase.favicon.svg` too, the project's [favicon](theme.md#logo-and-favicon) or Protobase's, and `/protobase.apple-touch-icon.png`, which it answers with the PNG [icons](app-identity.md#the-icons) the project has.
+- **Theme:** the page links `/protobase.theme.css`, which the dev server answers from the project's [theme](theme.md), checked as the build checks it, on every request, so an edit shows on the next reload. It links `/protobase.favicon.svg` too, the project's [favicon](theme.md#logo-and-favicon) or a neutral mark, and `/protobase.apple-touch-icon.png`, which it answers with the PNG [icons](app-identity.md#the-icons) the project has.
 - **Extensions:** `--extend <dir>` merges an extension in, its UI built into the dev page beside the project's, to try one out; its files reload like the project's.
 - **Hot reload:** server code, data configs, `ui.ts` views, layouts and the config are loaded through Vite's SSR module graph, and the config is read again with each rebuild. A change inside the project (or, in this repository, in `packages/server`, `packages/query`, `packages/schema`) rebuilds the API on the next request without a restart; `/meta` and `X-Meta-Version` change, so open tabs refetch. The database pool survives reloads. Newly added `ui.ts` files appear after the next change inside the project.
 
@@ -189,7 +213,7 @@ dist/
     plugins/app/            the project's protobase.ui.tsx, built as a plugin
     plugins/<extension>/    each --extend folder's protobase.ui.tsx, built as a plugin
     protobase.theme.css     the project's theme, checked and minified; empty without one
-    protobase.favicon.svg   the project's favicon; Protobase's without one
+    protobase.favicon.svg   the project's favicon; a neutral mark without one
     protobase.*.png         the project's PNG icons, the ones it has (see App identity)
   protobase.bundle.json     the manifest
 ```
@@ -419,6 +443,7 @@ Serves the API of a bundle from `protobase build` and owns the process around it
 | `PROTOBASE_ASSISTANT_URL`, `PROTOBASE_ASSISTANT_API_KEY`, `PROTOBASE_ASSISTANT_MODEL`, `PROTOBASE_ASSISTANT_BASE_URL` | the [assistant](assistant.md#which-backend): a backend elsewhere, or the built-in one on OpenRouter or another OpenAI-compatible endpoint; without them there is none |
 | `PROTOBASE_ASSISTANT_CHATS` | the folder the built-in assistant keeps its conversations in; default `.protobase/chats` |
 | `PROTOBASE_FIRST_ADMIN_URL` | the hosting platform's page where the app's first user is added, such as its console's; while the app has no users, the sign-in page links there in place of the `protobase users create` command ([the first admin](auth.md#first-run)) |
+| `PROTOBASE_RUNS_ON_NOTE` | `true` ends the sign-in page on the [Runs on Protobase note](app-identity.md#runs-on-protobase-note), for a hosting platform; default `false`, and any value but `true` or `false` stops startup |
 | `PROTOBASE_RUNTIME_URL` | the endpoint behind the top bar's [runtime update button](versioning.md#runtime-updates), such as a hosting platform's; without it there is no button |
 | `PROTOBASE_SENTRY_DSN` | the DSN of a Sentry-compatible error tracker the app's server and admin app send their errors to, after the config's `errorReporting` ([Error reporting](api.md#error-reporting)); without it nothing is sent |
 | `PROTOBASE_MAP_STYLE_URL` | the URL of the MapLibre style the record page's [maps](ui-config.md#maps) are drawn with, after the config's `maps`; without it there are no maps |
@@ -469,6 +494,7 @@ An Android or iOS app built with `mobile.publicKey` updates itself from the serv
 A host that serves bundles without running their config, such as a router in front of many apps or a static host, serves the same release from the files it already serves with `@protobase/server/mobile-release`, which loads none of the rest of the server: `protobase serve` composes its own release with the same exports.
 
 - `nativeFingerprint(native, plugins)`: the release's fingerprint, from the manifest's `native` (or that of the shell the host serves) and `mobile.plugins`. It is a contract across versions: a binary one Protobase release built is matched by a host that runs another.
+- `releaseOrder({ builtAt, shell })`: the order a release signs, from the manifest's build time and that of the server's own shell the host serves in its place, `[builtAt, 0]` with the bundle's copy; `undefined` when either names no build time.
 - `withApiOrigin(html, origin)`: the `spa` page naming the API origin, the app's `url`.
 - `composeRelease(files, signing?)`: the release of `{ href, content }` files, every file the host serves the web with the page above in place of `spa`, with its id and, with `signing`, `{ key, binding: { order, appId, fingerprint, shellVersion } }`, `appId` the manifest's `mobile.appId`, the signed checksums and statement.
 - `readSigningKey(env)`: the signing key in `PROTOBASE_MOBILE_SIGNING_KEY` of the env object given, the app's own, never the process's.
@@ -569,7 +595,7 @@ Applies the project's `db/migrations/*.sql` that the database has not applied ye
 protobase migration [--dir db/migrations] [--extend <dir>]
 ```
 
-Writes what the database still needs for every feature the config enables, as the project's next migrations in `--dir`, one file per feature: the auth schema when sign-in is on (`NNN_auth.sql`, as [`auth migration`](#auth-migration) writes it), the [jobs schema](jobs.md#the-jobs-schema) when the config has jobs, `webhooks` or `notifications`, or a resource has events, history, comments or an [AI field](ai.md) (`NNN_jobs.sql`), the [capture of events](events.md#migrations-and-startup) and the [history table](history.md#the-table) (`NNN_changes.sql`), the columns of [rollup and formula fields](data-config.md#rollups-and-formulas) and the triggers that keep the rollups (`NNN_computed.sql`), the role the [assistant's read-only queries](assistant.md#the-built-in-backend) run as, when it finds the built-in assistant's key (`NNN_query.sql`), the [comments table](comments.md#the-table) (`NNN_comments.sql`), the [webhook subscriptions](webhooks.md#subscriptions-in-the-admin-app) of `webhooks` (`NNN_webhooks.sql`), the [devices and history tables](notifications.md#table-names) of `notifications` (`NNN_notifications.sql`), the `realtime_relay` schema of [`realtime: { processes: 'many' }`](supabase-realtime.md#several-processes) (`NNN_realtime_relay.sql`), and the `channels` schema of [`realtime: { sqlSends: true }`](channels.md#from-sql) (`NNN_channel_sends.sql`). It compares the database, with the project's migrations applied, with the config (for the auth schema, it reads the store's record of the migrations it applied), merged with those of `--extend` as `dev` merges them, and writes nothing when the database is current. Apply the files with the project's other migrations. It reads the `.env` nearest the current directory and needs `DATABASE_URL`.
+Writes what the database still needs for every feature the config enables, as the project's next migrations in `--dir`, one file per feature: the auth schema when sign-in is on (`NNN_auth.sql`, as [`auth migration`](#auth-migration) writes it), the [jobs schema](jobs.md#the-jobs-schema) when the config has jobs, `webhooks` or `notifications`, or a resource has events, history, comments or an [AI field](ai.md) (`NNN_jobs.sql`), the [capture of events](events.md#migrations-and-startup) and the [history table](history.md#the-table) (`NNN_changes.sql`), the columns of [rollup and formula fields](data-config.md#rollups-and-formulas) and the triggers that keep the rollups (`NNN_computed.sql`), the role the [assistant's read-only queries](assistant.md#the-built-in-backend) run as, when it finds the built-in assistant's key (`NNN_query.sql`), the [comments table](comments.md#the-table) (`NNN_comments.sql`), the [webhook subscriptions](webhooks.md#subscriptions-in-the-admin-app) of `webhooks` (`NNN_webhooks.sql`), the [devices and history tables](notifications.md#table-names) of `notifications` (`NNN_notifications.sql`), the `realtime_relay` schema of [`realtime: { processes: 'many' }`](supabase-realtime.md#several-processes) (`NNN_realtime_relay.sql`), the `channels` schema of [`realtime: { sqlSends: true }`](channels.md#from-sql) (`NNN_channel_sends.sql`), and, with [`userTables`](user-tables.md#the-switch), the schemas of user tables (`NNN_user_tables.sql`) and the delete of the definitions of tables that resources in code [own now](user-tables.md#taking-a-table-over-as-code) (`NNN_owned_definitions.sql`). It compares the database, with the project's migrations applied, with the config (for the auth schema, it reads the store's record of the migrations it applied), merged with those of `--extend` as `dev` merges them, and writes nothing when the database is current. Apply the files with the project's other migrations. It reads the `.env` nearest the current directory and needs `DATABASE_URL`.
 
 ```sh
 bun run db:migrate                # the database at the project's current schema

package/skills/protobase/references/reference/custom-components.md

@@ -238,7 +238,7 @@ A component that asks for input looks like the app's own forms when it is built
 | `Choices` | One of a few options, each a card in a row of its own with a `description`: `name`, `label`, `options`, `value`, `onChange`. A `disabled` option shows and cannot be chosen. |
 | `RecordPicker` | Records of another resource, picked as the create form picks a relation: type to narrow them by their search fields or title, scroll for more, or use the keyboard. `resource` names the resource, whose model it reads from the app; `value` is the chosen record's key as text and `onChange` gets the new one. With `multiple`, `value` and `onChange` hold several keys, such as the objectives a task serves through a join resource: each shows as a token that can be taken off. |
 | `Segmented`, `MenuSelect` | A switch between a few short options in a row (`size`, `iconOnly`), and the same options in a menu. |
-| `Button`, `buttonClass` | A button (`variant` `primary`, `secondary`, `ghost` or `danger`, `size`, `loading`), and its classes for a link that looks like one. |
+| `Button`, `buttonClass` | A button (`variant` `primary`, `secondary`, `ghost` or `danger`, `size` `sm`, `md` or `icon`, a square for an icon alone, and `loading`), and its classes for a link that looks like one. |
 | `Dialog`, `ResponsiveDialog` | A modal with a `title`, `description`, `actions` and a body, which Escape and a click outside close with `onClose`; the responsive one becomes a sheet from the bottom of a phone, which a swipe down on its header closes too. |
 
 ```tsx

package/skills/protobase/references/reference/notifications.md

@@ -206,7 +206,7 @@ export const PushButton = () => {
 - Call `turnOn` straight from a click. The browser asks for permission then, and only then: without a click nothing happens, and push is never turned on when a page loads. Once the user said no, `turnOn` does not ask again and answers `blocked`. `state` is read again on a return to the page and when the browser says the permission changed, so it turns from `blocked` to `off` once the user allows notifications.
 - Only someone signed in as themselves can turn push on: a visitor's click and staff signed in as the user do nothing.
 - On iPhone and iPad, push works in the app added to the Home Screen; a browser tab answers `unsupported`.
-- Signing out turns push off in this browser, and so does someone else signing in on it: what the browser showed is closed, the app's badge cleared, and the device removed. Signing in again as the same user keeps it on.
+- Signing out turns push off in this browser, and so does someone else signing in on it: what the browser showed is closed, the app's badge cleared, and the device removed. Signing in again as the same user keeps it on. Each push names the user its device is registered for, and the browser shows nothing of a push for another user than the one it holds push for.
 - A tap on a notification whose url is on your app's origin opens that page in the app, in an open window of it or a new one; any other url opens in a new tab.
 
 `protobase serve` and `protobase dev` both serve the service worker that shows notifications, `protobase dev` only when the app has `notifications`.

package/skills/protobase/references/reference/theme.md

@@ -123,9 +123,9 @@ The list is `packages/ui/src/tokens.css`, and a test fails when one of its token
 
 ## Logo and favicon
 
-The sidebar's logo is the project's own favicon, or Protobase's mark without one, beside the app's [name](app-identity.md#the-name), with the organization the user works in under it, and the icon alone when the sidebar shows only icons. An app that keeps Protobase's name and has no favicon of its own shows Protobase's wordmark beside the mark. A project draws something else with `shell.logo` in `protobase.ui.tsx`, a component drawn in its place ([Shell slots](custom-components.md#shell-slots)); it draws with these tokens like the rest of the app.
+The sidebar's logo is the project's own favicon, or without one the app's initial when it has a name of its own and Protobase's mark when it keeps Protobase's, beside the app's [name](app-identity.md#the-name), with the organization the user works in under it, and the icon alone when the sidebar shows only icons. An app that keeps Protobase's name and has no favicon of its own shows Protobase's wordmark beside the mark. A project draws something else with `shell.logo` in `protobase.ui.tsx`, a component drawn in its place ([Shell slots](custom-components.md#shell-slots)); it draws with these tokens like the rest of the app.
 
-The browser tab shows Protobase's mark. A project shows its own with a `protobase.favicon.svg` at its root, beside `protobase.theme.css`: the app's `index.html` links `/protobase.favicon.svg`, which `protobase build` writes to the bundle's `public/`, the project's file or Protobase's without one, and which `protobase dev` serves the same way. An SVG can follow the system's light or dark with a `prefers-color-scheme` media query inside it, as Protobase's does. PNGs beside it serve the platforms that take no SVG, such as an iPhone's home screen ([App identity](app-identity.md#the-icons)).
+The browser tab shows a neutral mark. A project shows its own with a `protobase.favicon.svg` at its root, beside `protobase.theme.css`: the app's `index.html` links `/protobase.favicon.svg`, which `protobase build` writes to the bundle's `public/`, the project's file or the neutral mark without one, and which `protobase dev` serves the same way. An SVG can follow the system's light or dark with a `prefers-color-scheme` media query inside it, as the neutral mark does. PNGs beside it serve the platforms that take no SVG, such as an iPhone's home screen ([App identity](app-identity.md#the-icons)).
 
 ## In a plugin
 

package/skills/protobase/references/reference/ui-config.md

@@ -667,7 +667,7 @@ export const repairsView = filtered
 
 A custom component draws only its part: the page around it stays the record page, at `/<resource>/<key>`, with its breadcrumbs, Save, the action rail with Edit and Delete, and the related records, and a layout may hold only custom components. The repairs above list the customer's earlier repairs under the bike:
 
-Without a layout the record page shows one section with every field the user may change; its [read view](#read-view-and-edit), which is what a user who may change none gets, shows every field. A section or sidebar card with no field the user may see is left out. The record's title is the page's heading, above the sections, with an enum `status` as a badge beside it unless the sidebar shows it already. `.saveFeedback('button')` shows saving on the Save button instead of a toast (`'toast'`, the default). A [sensitive field](data-config.md#sensitive-fields) in a section is masked, with an eye button that reveals it. A [write-only field](access.md#write-only-fields) is on the form only where a section names it, never in the section without a layout, and shows as an empty input to set a new value in.
+Without a layout the record page shows one section with every field the user may change; its [read view](#read-view-and-edit), which is what a user who may change none gets, shows every field. A section or sidebar card with no field the user may see is left out. On a wide screen the sidebar cards stay in view beside the main column as the page scrolls, below the top bar. The record's title is the page's heading, above the sections, with an enum `status` as a badge beside it unless the sidebar shows it already. `.saveFeedback('button')` shows saving on the Save button instead of a toast (`'toast'`, the default). A [sensitive field](data-config.md#sensitive-fields) in a section is masked, with an eye button that reveals it. A [write-only field](access.md#write-only-fields) is on the form only where a section names it, never in the section without a layout, and shows as an empty input to set a new value in.
 
 A record opened from a list, by its row or its card, shows the fields the list loaded at once, with placeholders for the others, and takes input once the whole record has loaded; actions, custom components, maps and galleries wait for it. What the page shows is read again whenever the browser tab or window regains focus, as are the lists, unless the record has unsaved changes, which keep the version they were made to.
 

package/skills/protobase/references/reference/user-tables.md

@@ -2,7 +2,7 @@
 
 # User tables
 
-The switch that keeps tables users add in the app's own database, the two schemas they live in, the migration that adds them, and how each one is served.
+The switch that keeps tables users add in the app's own database, the two schemas they live in, the migration that adds them, how each one is served, and how a developer takes one over as code.
 
 An app's resources usually come from its code: a resource in `config/` over a table a migration made. With user tables on, the app also keeps tables its users add in its own database, and serves each one beside the resources in code.
 
@@ -61,7 +61,7 @@ When the server starts, and whenever the definitions change, it builds a resourc
 - **A definition that does not fit is left out.** A definition with a name or type outside the rules above, or whose table or columns do not match it, is not served, and the server prints why at start. The rest of the app serves.
 - **Code wins.** A resource in code with the name of a user table, or a resource Protobase adds, is served instead of the definition, which is then ignored with a warning. This is how a table users added is taken over as code.
 
-[`protobase doctor`](cli.md#doctor) checks each definition against the database as it checks the resources in code, and reports each one it leaves out as an error. [`protobase scaffold`](cli.md#scaffold) leaves out the definitions and the tables in `user_tables` that no resource in code claims, and writes and updates the config of one that a resource claims.
+[`protobase doctor`](cli.md#doctor) checks each definition against the database as it checks the resources in code, reports each one it leaves out as an error, and checks a table a resource in code has taken over as that resource. [`protobase scaffold`](cli.md#scaffold) leaves out the definitions and the tables in `user_tables` that no resource in code claims, and writes and updates the config of one that a resource claims.
 
 ### How a change reaches every process
 
@@ -120,3 +120,22 @@ The answer has the table's record, so a client links to the new table at `/notes
 - **The rest of the app.** The process that made the change serves it before it answers, and every other process [within a second](#how-a-change-reaches-every-process). While a deploy freezes writes, a create answers as any write does then.
 
 Building an index holds the table's write lock, and every statement runs within the request's statement timeout (1 s by default). <gap>Adding a field to a table with very many records cannot finish when building its index takes longer than the statement timeout, because building it outside the request is not implemented; the field is then not added.</gap>
+
+## Taking a table over as code
+
+:::caution[Beta]
+A table is taken over from the command line alone, keeps its name and stays in `user_tables`.
+:::
+
+`protobase eject` turns a table someone added in the admin app into ordinary config and a migration in the project, so a developer can customise it like any other resource. Its records stay where they are.
+
+When a table needs more than the admin app gives it, such as a validation rule, a view per role or an action, [`protobase eject <table>`](cli.md#eject) writes its `config/<table>/data.ts` and `ui.ts`, as the server serves it from its definition, and a migration that makes the table as it is. The resource reads `user_tables.<table>`, where the table already is, so the deploy that brings the code moves no row: the migration changes nothing on that database and makes the same table on an empty one, such as a developer's. From then on it is a resource like any other, and the config is yours to change.
+
+1. **Get the project and its database.** For an app you host yourself, work in its repository with its database URL in `DATABASE_URL`, or pass the URL as the first argument. For an app on Protobase Cloud, clone the repository the app deploys from and use the app's database URL.
+2. **Eject.** Run `protobase eject <table>`, or name several tables. It runs [`doctor`](cli.md#doctor) on what it wrote and puts every file back when doctor fails.
+3. **Deploy soon.** Commit the files and deploy as usual: for an app on Protobase Cloud, push to the branch it follows (see [Protobase Cloud](../guides/deploy.md#protobase-cloud)). Until the new version serves, the admin app still adds fields to the table, which the new config does not have: add such a field with [`protobase scaffold user_tables.<table>`](cli.md#scaffold) and a migration of its own that adds the column.
+4. **Delete the definition in a later deploy.** Once the code has deployed, run [`protobase migration`](cli.md#migration): it writes the delete of each definition whose table a resource in code reads under the same name (`NNN_owned_definitions.sql`), which goes out with the next deploy. Its table and rows stay. Until then the server ignores the definition, as [code wins](#how-each-one-is-served), and doctor warns about it. <gap>`protobase migration` cannot hold the delete back when it runs before the eject has deployed because telling which version serves is not implemented; the old version then stops serving the table for the moment before the new one serves.</gap>
+
+Once the code serves, the table takes no new field from the admin app, and a new table cannot take its name. The resource starts as the admins' alone, as it was served; widen its access in `data.ts` as for any resource.
+
+<gap>A table cannot be taken over from the admin app or the assistant because an eject that writes to the project's repository is not implemented.</gap>

package/skills/protobase/references/reference/versioning.md

@@ -45,7 +45,7 @@ Every commit message follows [Conventional Commits](https://www.conventionalcomm
 `.github/workflows/release.yml` runs on every push to `main`:
 
 1. The checks of `ci.yml` (`bun run check`, the smoke test on Node, the docs build, the Storybook play tests and the docs check), of the tests and steps the changes since the last `v<version>` tag affect (see What a push checks in `CONTRIBUTING.md`), and commitlint over the pushed commits. The Postgres suite (`bun run test:postgres`, on Postgres and PgBouncer) runs in full as well, whatever changed, beside the other checks. They start at once, and the release waits for them all.
-2. `bun run release` (`scripts/release.mjs`, with [commit-and-tag-version](https://github.com/absolute-version/commit-and-tag-version)) computes the next version and its notes from the commits since the last `v<version>` tag, as above, and tags the pushed commit `v<version>`. It commits nothing and changes no file. Without a fix, feature or breaking change it tags nothing.
+2. `bun run release` (`scripts/release.mjs`, with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)) computes the next version and its notes from the commits since the last `v<version>` tag, as above, and tags the pushed commit `v<version>`. A squash-merged pull request counts with each commit its body lists as a `* ` item, so one titled `chore` that carries a fix or feature is released; an item an older commit since the tag lists already counts once. It commits nothing and changes no file. Without a fix, feature or breaking change it tags nothing.
 3. The tag is pushed, and the GitHub release of the tag gets the notes.
 4. Beside the checks, a pack job takes the tag `bun run release --dry-run` predicts, and `scripts/stamp-version.mjs` writes its version into every `package.json` and `bun.lock` in the runner, never committed. `scripts/publish.mjs --pack --out` then builds every package to `dist` and packs it with Bun (the private `@protobase/presets` is not published). Once the tag is pushed, npm, under Node, publishes those tarballs with [trusted publishing](https://docs.npmjs.com/trusted-publishers) and provenance (`scripts/publish.mjs --from`); there is no npm token, and only the publish job holds the identity token it needs. A tag other than the version the tarballs were stamped with fails the publish before anything is uploaded, and a run that cut no release packs and publishes nothing.
 5. Once npm serves the packages, the tag's version is written into the `package.json` files the same way, and `bun run images:context <image>` writes each image's build context at the tag from them, and the images are built natively for `linux/amd64` and `linux/arm64` and pushed to GitHub's registry as `ghcr.io/prototeamhq/protobase:<version>` and `ghcr.io/prototeamhq/protobase-dev:<version>` (see [Deploy](../guides/deploy.md#images)). A release whose publish failed has no images.