clivly 0.9.6 → 0.10.0

package/{entity-config-B2RA53nw.d.cts → entity-config-DNQAMbMS.d.cts}

@@ -2137,6 +2137,23 @@ declare const ZodReadonly: $constructor<ZodReadonly>;
  */
 /** The reserved ref name for the projection's base table. */
 declare const BASE_REF = "base";
+/**
+ * Entity keys become view names (`crm_src_<entityKey>`), so keep them slugs.
+ *
+ * Accepts hyphens as well as underscores, matching `OBJECT_TYPE_SLUG_PATTERN`
+ * on the server. Those two were widened apart: the server learned hyphens
+ * because the SDK's own `slugify` collapses non-alphanumerics to them and
+ * `clivly status` reports that form as canonical — but this pattern was missed,
+ * so `clivly status` would tell you to key an entity `client-accounts` and then
+ * `defineClivlyConfig` would reject the config it had just asked for. Same bug,
+ * opposite half of the product.
+ *
+ * Widening is the safe direction: every key that was valid before still is, so
+ * nothing existing is renamed. Safe at all because neither use is ever a bare
+ * SQL identifier — the view name is quoted (`view-compiler.ts`, `quoteIdent`),
+ * and so is a join's `key` when it is emitted as an alias.
+ */
+declare const PROJECTION_KEY_PATTERN: RegExp;
 declare const projectionRefSchema: ZodObject<{
   table: ZodString;
   column: ZodString;
@@ -2638,6 +2655,15 @@ declare function customObjectDeclarations(config: ClivlyEntitiesConfig): CustomO
  * Qualified rather than bare: two bindings can pull the same column name from
  * different tables (`cl.full_name` and `adv.full_name`), which a bare column
  * name cannot tell apart.
+ *
+ * This is the single derivation of that map, and both consumers depend on it
+ * emitting ref tokens. `mappingsToEntitiesConfig` populates a projection
+ * entity's required `fields`; the cloud ingest path needs the same map because
+ * a projection's persisted `crm_entity_mappings.field_map` is empty by design,
+ * so `rowToSourceRow` derives the effective field map from the projection
+ * instead. The tokens emitted here are exactly how `fromDrizzleProjection` keys
+ * the rows it pushes (`drizzle-projection.ts` `refToken`), so the two line up.
+ * Deriving this a second time anywhere would let the copies drift.
  */
 declare function projectionFields(projection: ProjectionMapping): Record<string, string>;
 declare function defineClivlyConfig(config: ClivlyEntitiesConfigInput, options?: {
@@ -2698,4 +2724,4 @@ interface ConfigValidationResult {
  */
 declare function validateEntitiesConfig(config: ClivlyEntitiesConfig, schema: DiscoveredSchemaTable[]): ConfigValidationResult;
 //#endregion
-export { BASE_REF as A, defineClivlyConfig as C, relationshipSchema as D, projectionFields as E, ProjectionRef as F, identityRefs as I, projectionSchema as L, ProjectionIdentity as M, ProjectionJoin as N, relationshipsSchema as O, ProjectionMapping as P, customObjectDeclarations as S, filterSchema as T, MATERIALIZING_CONCEPTS as _, ClivlyEntitiesConfig as a, RelationshipVia as b, ClivlyEntityConfigInput as c, CrmConcept as d, CustomObjectDeclaration as f, FilterValue as g, FilterExpr as h, ClivlyConfigError as i, ProjectionFieldBinding as j, validateEntitiesConfig as k, ConfigValidationError as l, DiscoveredSchemaTable as m, CRM_CONCEPTS as n, ClivlyEntitiesConfigInput as o, DiscoveredColumnMeta as p, CUSTOM_CONCEPT as r, ClivlyEntityConfig as s, CANONICAL_FIELDS as t, ConfigValidationResult as u, MaterializingConcept as v, entitiesConfigSchema as w, RelationshipsMap as x, RelationshipSpec as y };
+export { BASE_REF as A, defineClivlyConfig as C, relationshipSchema as D, projectionFields as E, ProjectionMapping as F, ProjectionRef as I, identityRefs as L, ProjectionFieldBinding as M, ProjectionIdentity as N, relationshipsSchema as O, ProjectionJoin as P, projectionSchema as R, customObjectDeclarations as S, filterSchema as T, MATERIALIZING_CONCEPTS as _, ClivlyEntitiesConfig as a, RelationshipVia as b, ClivlyEntityConfigInput as c, CrmConcept as d, CustomObjectDeclaration as f, FilterValue as g, FilterExpr as h, ClivlyConfigError as i, PROJECTION_KEY_PATTERN as j, validateEntitiesConfig as k, ConfigValidationError as l, DiscoveredSchemaTable as m, CRM_CONCEPTS as n, ClivlyEntitiesConfigInput as o, DiscoveredColumnMeta as p, CUSTOM_CONCEPT as r, ClivlyEntityConfig as s, CANONICAL_FIELDS as t, ConfigValidationResult as u, MaterializingConcept as v, entitiesConfigSchema as w, RelationshipsMap as x, RelationshipSpec as y };

package/{entity-config-B2RA53nw.d.mts → entity-config-DNQAMbMS.d.mts}

@@ -2137,6 +2137,23 @@ declare const ZodReadonly: $constructor<ZodReadonly>;
  */
 /** The reserved ref name for the projection's base table. */
 declare const BASE_REF = "base";
+/**
+ * Entity keys become view names (`crm_src_<entityKey>`), so keep them slugs.
+ *
+ * Accepts hyphens as well as underscores, matching `OBJECT_TYPE_SLUG_PATTERN`
+ * on the server. Those two were widened apart: the server learned hyphens
+ * because the SDK's own `slugify` collapses non-alphanumerics to them and
+ * `clivly status` reports that form as canonical — but this pattern was missed,
+ * so `clivly status` would tell you to key an entity `client-accounts` and then
+ * `defineClivlyConfig` would reject the config it had just asked for. Same bug,
+ * opposite half of the product.
+ *
+ * Widening is the safe direction: every key that was valid before still is, so
+ * nothing existing is renamed. Safe at all because neither use is ever a bare
+ * SQL identifier — the view name is quoted (`view-compiler.ts`, `quoteIdent`),
+ * and so is a join's `key` when it is emitted as an alias.
+ */
+declare const PROJECTION_KEY_PATTERN: RegExp;
 declare const projectionRefSchema: ZodObject<{
   table: ZodString;
   column: ZodString;
@@ -2638,6 +2655,15 @@ declare function customObjectDeclarations(config: ClivlyEntitiesConfig): CustomO
  * Qualified rather than bare: two bindings can pull the same column name from
  * different tables (`cl.full_name` and `adv.full_name`), which a bare column
  * name cannot tell apart.
+ *
+ * This is the single derivation of that map, and both consumers depend on it
+ * emitting ref tokens. `mappingsToEntitiesConfig` populates a projection
+ * entity's required `fields`; the cloud ingest path needs the same map because
+ * a projection's persisted `crm_entity_mappings.field_map` is empty by design,
+ * so `rowToSourceRow` derives the effective field map from the projection
+ * instead. The tokens emitted here are exactly how `fromDrizzleProjection` keys
+ * the rows it pushes (`drizzle-projection.ts` `refToken`), so the two line up.
+ * Deriving this a second time anywhere would let the copies drift.
  */
 declare function projectionFields(projection: ProjectionMapping): Record<string, string>;
 declare function defineClivlyConfig(config: ClivlyEntitiesConfigInput, options?: {
@@ -2698,4 +2724,4 @@ interface ConfigValidationResult {
  */
 declare function validateEntitiesConfig(config: ClivlyEntitiesConfig, schema: DiscoveredSchemaTable[]): ConfigValidationResult;
 //#endregion
-export { BASE_REF as A, defineClivlyConfig as C, relationshipSchema as D, projectionFields as E, ProjectionRef as F, identityRefs as I, projectionSchema as L, ProjectionIdentity as M, ProjectionJoin as N, relationshipsSchema as O, ProjectionMapping as P, customObjectDeclarations as S, filterSchema as T, MATERIALIZING_CONCEPTS as _, ClivlyEntitiesConfig as a, RelationshipVia as b, ClivlyEntityConfigInput as c, CrmConcept as d, CustomObjectDeclaration as f, FilterValue as g, FilterExpr as h, ClivlyConfigError as i, ProjectionFieldBinding as j, validateEntitiesConfig as k, ConfigValidationError as l, DiscoveredSchemaTable as m, CRM_CONCEPTS as n, ClivlyEntitiesConfigInput as o, DiscoveredColumnMeta as p, CUSTOM_CONCEPT as r, ClivlyEntityConfig as s, CANONICAL_FIELDS as t, ConfigValidationResult as u, MaterializingConcept as v, entitiesConfigSchema as w, RelationshipsMap as x, RelationshipSpec as y };
+export { BASE_REF as A, defineClivlyConfig as C, relationshipSchema as D, projectionFields as E, ProjectionMapping as F, ProjectionRef as I, identityRefs as L, ProjectionFieldBinding as M, ProjectionIdentity as N, relationshipsSchema as O, ProjectionJoin as P, projectionSchema as R, customObjectDeclarations as S, filterSchema as T, MATERIALIZING_CONCEPTS as _, ClivlyEntitiesConfig as a, RelationshipVia as b, ClivlyEntityConfigInput as c, CrmConcept as d, CustomObjectDeclaration as f, FilterValue as g, FilterExpr as h, ClivlyConfigError as i, PROJECTION_KEY_PATTERN as j, validateEntitiesConfig as k, ConfigValidationError as l, DiscoveredSchemaTable as m, CRM_CONCEPTS as n, ClivlyEntitiesConfigInput as o, DiscoveredColumnMeta as p, CUSTOM_CONCEPT as r, ClivlyEntityConfig as s, CANONICAL_FIELDS as t, ConfigValidationResult as u, MaterializingConcept as v, entitiesConfigSchema as w, RelationshipsMap as x, RelationshipSpec as y };

package/{entity-config-DE30_RpU.cjs → entity-config-DgAe0_YD.cjs}

@@ -1,4 +1,4 @@
-const require_projection = require("./projection-DEwL-D8R.cjs");
+const require_projection = require("./projection-Dz6_i1-w.cjs");
 //#region ../core/src/schema-meta.ts
 /**
 * Accessors over a discovered table's schema-v2 metadata.
@@ -29,7 +29,17 @@ function coversUniqueKey(table, columns) {
 	const present = new Set(columns);
 	return (table.uniqueConstraints ?? []).some((key) => key.length > 0 && key.every((column) => present.has(column)));
 }
-/** Is this table's payload rich enough to validate a projection against? */
+/**
+* Is this table's payload rich enough to validate a projection against?
+*
+* A type predicate rather than a plain boolean so the narrowing is visible to
+* the compiler: callers that guard on this can iterate `columnsMeta` directly
+* instead of casting, and a cast that outlives its guard becomes a type error
+* rather than a silent walk over `undefined`.
+*
+* The invariant is unchanged: this reports whether the metadata is *known*,
+* never whether the table has keys. Absent metadata stays UNKNOWN.
+*/
 function hasRichMeta(table) {
 	return Boolean(table.columnsMeta && table.uniqueConstraints);
 }
@@ -137,7 +147,7 @@ function checkTablesExist(errors, projection, resolver, base) {
 		if (!hasRichMeta(table)) {
 			errors.push({
 				path,
-				message: `table "${name}" has no key/column metadata — upgrade @clivly/sdk and re-run discovery before using a projection`
+				message: `table "${name}" was discovered without column types or unique keys, which a projection needs to prove its id is unique. Redeploy or restart the app so it re-reports its schema (or run \`clivly push-schema\`); if the table is declared by hand as \`{ name, columns }\`, use \`discoverFromDrizzle\` so keys and types come with it.`
 			});
 			ok = false;
 		}
@@ -182,10 +192,27 @@ function checkRefs(errors, projection, resolver, base, basePk) {
 	for (const [field, binding] of Object.entries(projection.fieldBindings)) checkRef(errors, resolver, `${base}.projection.fieldBindings.${field}`, binding.from);
 	for (const ref of require_projection.identityRefs(projection.identity, basePk)) checkRef(errors, resolver, `${base}.projection.identity`, ref);
 }
+/**
+* Prove that a single-column identity (`column`, or `base_pk` with an
+* explicit column) is actually unique.
+*
+* `coversUniqueKey` fails closed on absent metadata, same as every other
+* check in this file: a column not provably covered by a unique key is
+* rejected, never assumed safe.
+*/
+function checkSingleColumnIdentity(errors, resolver, path, ref) {
+	const table = resolver.tableFor(ref.table);
+	if (!table) return;
+	if (!coversUniqueKey(table, [ref.column])) errors.push({
+		path,
+		message: `identity column "${ref.table}.${ref.column}" is not covered by a unique key of "${table.name}" — pick a column with a unique constraint, or use a composite identity that is`
+	});
+}
 function checkIdentitySafety(errors, projection, resolver, base, baseTable) {
 	const path = `${base}.projection.identity`;
 	const pk = primaryKeyColumns(baseTable);
-	if (projection.identity.kind === "base_pk" && !projection.identity.column) {
+	const { identity } = projection;
+	if (identity.kind === "base_pk" && !identity.column) {
 		if (pk.length === 0) {
 			errors.push({
 				path,
@@ -200,9 +227,21 @@ function checkIdentitySafety(errors, projection, resolver, base, baseTable) {
 			});
 			return;
 		}
+		return;
+	}
+	if (identity.kind === "base_pk" && identity.column) {
+		checkSingleColumnIdentity(errors, resolver, path, {
+			table: require_projection.BASE_REF,
+			column: identity.column
+		});
+		return;
 	}
-	if (projection.identity.kind !== "composite") return;
-	for (const part of projection.identity.parts) {
+	if (identity.kind === "column") {
+		checkSingleColumnIdentity(errors, resolver, path, identity.from);
+		return;
+	}
+	if (identity.kind !== "composite") return;
+	for (const part of identity.parts) {
 		const table = resolver.tableFor(part.table);
 		const meta = table && columnMetaFor(table, part.column);
 		if (!meta) continue;
@@ -244,6 +283,64 @@ function checkFanOut(errors, projection, resolver, base, basePk) {
 	});
 }
 /**
+* One error naming a filter column that is not on the projection's base table,
+* and the base table it would have to be on.
+*/
+function columnOnBase(column, baseTable, path) {
+	if (baseTable?.columns.includes(column)) return [];
+	return [{
+		path,
+		message: `filter column "${column}" does not exist on "${baseTable?.name ?? "the base table"}" — a derived object is filtered by its base table's columns only, so name one of those, or move the condition into a join's \`on\``
+	}];
+}
+/**
+* A derived object's filter is evaluated in the cloud against pushed rows, so
+* it can only name columns of the base table.
+*
+* Every rejected shape here fails *silently* today, which is the whole reason
+* the check exists — a filter that cannot be honoured must error, never quietly
+* return the wrong rows. The three shapes fail in different directions:
+*
+* - `$raw` is opaque SQL meant for the embedded model. The cloud path cannot
+*   evaluate it and passes every row, so the filter is ignored and the object
+*   syncs UNFILTERED.
+* - A joined-table column resolves to nothing on a pushed row, so under a
+*   positive operator (`eq`, `in`) no row matches and the object syncs EMPTY.
+* - The same unresolvable column under a NEGATIVE operator (`ne`, `isNull`,
+*   `notIn`) is the dangerous one: the missing cell reads as null, so the
+*   predicate is true for every row and a filter meant to narrow the sync
+*   ADMITS EVERYTHING. Nobody notices extra rows arriving.
+*
+* Rejecting an unresolvable column closes the last two together.
+*/
+function validateProjectionFilter(filter, projection, schema, base) {
+	if (!filter) return [];
+	const path = `${base}.filter`;
+	if ("$raw" in filter) return [{
+		path,
+		message: "a $raw filter cannot be evaluated against a derived object's rows — it is opaque SQL, so the cloud passes every row through unfiltered. Express it as column conditions on the base table instead"
+	}];
+	const baseTable = schema.find((t) => t.name === projection.baseTable);
+	const errors = [];
+	for (const column of Object.keys(filter)) {
+		if (column.includes(".")) {
+			const [ref, ...rest] = column.split(".");
+			const bare = rest.join(".");
+			if (ref !== "base") {
+				errors.push({
+					path,
+					message: `filter column "${column}" names the join "${ref}", but a derived object is filtered by its base table ("${projection.baseTable}") only — filter on a base column, or move the condition into that join's \`on\``
+				});
+				continue;
+			}
+			errors.push(...columnOnBase(bare, baseTable, path));
+			continue;
+		}
+		errors.push(...columnOnBase(column, baseTable, path));
+	}
+	return errors;
+}
+/**
 * Validate a projection against the discovered schema. Returns every error
 * found (not just the first) so a builder UI can show them all at once.
 */
@@ -516,6 +613,15 @@ function customObjectDeclarations(config) {
 * Qualified rather than bare: two bindings can pull the same column name from
 * different tables (`cl.full_name` and `adv.full_name`), which a bare column
 * name cannot tell apart.
+*
+* This is the single derivation of that map, and both consumers depend on it
+* emitting ref tokens. `mappingsToEntitiesConfig` populates a projection
+* entity's required `fields`; the cloud ingest path needs the same map because
+* a projection's persisted `crm_entity_mappings.field_map` is empty by design,
+* so `rowToSourceRow` derives the effective field map from the projection
+* instead. The tokens emitted here are exactly how `fromDrizzleProjection` keys
+* the rows it pushes (`drizzle-projection.ts` `refToken`), so the two line up.
+* Deriving this a second time anywhere would let the copies drift.
 */
 function projectionFields(projection) {
 	const fields = {};
@@ -654,7 +760,7 @@ function validateEntity(v, config, key, entity, schema) {
 		if (entity.source !== entity.projection.baseTable) v.report(`${base}.source`, `"source" ("${entity.source}") must match "projection.baseTable" ("${entity.projection.baseTable}") — the view compiler reads baseTable and the sync engine reads source, so a mismatch makes them disagree about which table this entity is`);
 		for (const error of validateProjection(entity.projection, schema, base)) v.report(error.path, error.message);
 		validateReadOnly(v, base, entity);
-		validateFilter(v, base, entity);
+		for (const error of validateProjectionFilter(entity.filter, entity.projection, schema, base)) v.report(error.path, error.message);
 		return;
 	}
 	validateFields(v, base, entity);
@@ -800,3 +906,9 @@ Object.defineProperty(exports, "validateProjection", {
 		return validateProjection;
 	}
 });
+Object.defineProperty(exports, "validateProjectionFilter", {
+	enumerable: true,
+	get: function() {
+		return validateProjectionFilter;
+	}
+});

package/index.cjs

@@ -1,9 +1,9 @@
 #!/usr/bin/env node
 Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
-const require_entity_config = require("./entity-config-DE30_RpU.cjs");
+const require_entity_config = require("./entity-config-DgAe0_YD.cjs");
 require("./mapping-score-CaB3F4Uu.cjs");
 const require_internal_entity_heuristics = require("./internal-entity-heuristics.cjs");
-const require_sdk = require("./sdk-w8Kv_XnW.cjs");
+const require_sdk = require("./sdk-B1vX4kUJ.cjs");
 let node_child_process = require("node:child_process");
 let node_fs = require("node:fs");
 let node_module = require("node:module");
@@ -306,16 +306,27 @@ function addCommand(pm, packages) {
 */
 const CLIVLY_TICK_PATH = "/api/clivly/tick";
 /**
-* What `clivly login` writes into `.env` for `CLIVLY_SYNC_TRIGGER_URL`.
+* The example shape `clivly init`/`clivly login` show for `CLIVLY_SYNC_TRIGGER_URL`
+* — commented out in `.env`, not written as a live value.
 *
-* A visible template beats an empty line: the developer sees the shape they
-* eventually need — a public origin plus the tick path — instead of an unhelpful
-* `CLIVLY_SYNC_TRIGGER_URL=` they have to go and look up.
+* It used to be scaffolded uncommented, on the theory that a visible template
+* beats an empty line. The SDK's `isPlaceholderUrl` guard
+* (`@clivly/sdk/trigger-url`) already keeps a bracketed placeholder like this
+* one out of `syncTrigger.url` on every heartbeat — `resolveTriggerUrl` skips
+* it in favour of the dev tunnel / platform-derived origin — and
+* `assertSafeTriggerUrl` on the API side rejects it outright if it were ever
+* sent, since `<yourDomain.com>` doesn't even parse as a URL. So it was never
+* actually fireable (F-12 is not an SSRF/overwrite bug).
 *
-* It is safe to ship a truthy non-address here only because the SDK refuses to
-* treat a bracketed value as configured (`isPlaceholderUrl` in
-* `@clivly/sdk/trigger-url`). Change the brackets here and that guard stops
-* matching, so the two must stay in step.
+* What it DID break: readiness reporting only checked *presence*, not
+* validity, so an unedited placeholder made the dashboard's setup ladder and
+* `triggerConfigured` report "done" while `clivly status` correctly flagged
+* it — two surfaces disagreeing about a workspace that could never run "Run
+* sync". See `hasWorkingTrigger` (`@clivly.com/api/sync-trigger`) for the
+* fix. Commenting the example out here removes the confusing truthy-but-fake
+* value at the source, on top of that fix, while keeping the shape visible
+* for the (uncommon) case a developer needs it — most platforms are
+* auto-detected, and `clivly dev` handles local development.
 */
 const TRIGGER_URL_PLACEHOLDER = `https://<yourDomain.com>${CLIVLY_TICK_PATH}`;
 //#endregion
@@ -1440,8 +1451,8 @@ function credentialEntries(credentials) {
 		},
 		{
 			key: "CLIVLY_SYNC_TRIGGER_URL",
-			value: TRIGGER_URL_PLACEHOLDER,
-			comment: "Public URL of your tick route — replace <yourDomain.com> once deployed. Local dev: run `clivly dev` instead."
+			value: "",
+			comment: `Public URL of your tick route. Only needed when the platform's own URL can't be auto-detected (see \`clivly status\`). Uncomment and set your deployed origin if so:\n# CLIVLY_SYNC_TRIGGER_URL=${TRIGGER_URL_PLACEHOLDER}`
 		}
 	];
 }
@@ -1810,8 +1821,7 @@ const CLIVLY_ENV_KEYS = [
 	},
 	{
 		key: "CLIVLY_SYNC_TRIGGER_URL",
-		value: TRIGGER_URL_PLACEHOLDER,
-		comment: "Public URL of your tick route — replace <yourDomain.com> once deployed. Local dev: run `clivly dev` instead."
+		comment: `Public URL of your tick route. Only needed when the platform's own URL can't be auto-detected (see \`clivly status\`). Uncomment and set your deployed origin if so:\n# CLIVLY_SYNC_TRIGGER_URL=${TRIGGER_URL_PLACEHOLDER}`
 	},
 	{
 		key: "CLIVLY_SYNC_TRIGGER_SECRET",
@@ -1871,6 +1881,7 @@ function renderImports(plan) {
 		"import { createClivlySDK, defineClivlyConfig } from \"clivly/sdk\";",
 		"import { fromDrizzle } from \"clivly/drizzle\";",
 		"import { discoverFromDrizzle } from \"clivly/drizzle\";",
+		"import { drizzleIntrospector } from \"clivly/drizzle\";",
 		`import * as schema from "${plan.importPath}";`
 	];
 	if (plan.db === null) {
@@ -1903,6 +1914,9 @@ export default createClivlySDK({
   // Every table in your Drizzle schema, so the Clivly dashboard can offer them
   // all when you add a mapping — not just the ones wired up as sources below.
   schema: discoverFromDrizzle(schema),
+  // Lets derived objects authored in the dashboard run against this database.
+  // Without it they are fetched, validated and then skipped.
+  introspector: drizzleIntrospector(${dbExpr}),
   source: {
     // Keyed by CRM concept — contacts/companies/deals/custom.
     // NOT by your entity key. The entity's own \`source:\` above is a table name.
@@ -3201,6 +3215,32 @@ const STATUS_STAGES = [
 		}
 	},
 	sdkChecksStage,
+	{
+		id: "derived-objects",
+		label: "Dashboard-authored objects",
+		needs: [configStage.id],
+		run(ctx) {
+			const remote = ctx.sdk?.describeRemoteProjections?.();
+			if (!remote) return Promise.resolve({
+				state: "skip",
+				detail: "This app's installed clivly predates dashboard-authored objects."
+			});
+			if (!remote.capable) return Promise.resolve({
+				state: "warn",
+				detail: "Objects authored in the dashboard cannot run against this app.",
+				hint: "Add `introspector: drizzleIntrospector(db)` to clivly.config.ts."
+			});
+			if (!remote.ran) return Promise.resolve({
+				state: "pass",
+				detail: "Ready; no sync has run in this process yet."
+			});
+			const broken = remote.invalid + remote.failed;
+			return Promise.resolve({
+				state: broken > 0 ? "warn" : "pass",
+				detail: broken > 0 ? `${remote.ok} running, ${broken} not — open the object in Clivly for the reason.` : `${remote.ok} running.`
+			});
+		}
+	},
 	triggerUrlStage
 ];
 function defaultLoadSdk(path) {
@@ -3254,7 +3294,8 @@ const ALIAS_STAGE_IDS = {
 		"config",
 		"runtime",
 		"boot-hook",
-		"setup-checks"
+		"setup-checks",
+		"derived-objects"
 	],
 	connect: [
 		"api-key",

package/index.mjs

@@ -1,8 +1,8 @@
 #!/usr/bin/env node
-import { t as CANONICAL_FIELDS } from "./entity-config-CusbTOJ1.mjs";
+import { t as CANONICAL_FIELDS } from "./entity-config-C4d3K9CP.mjs";
 import "./mapping-score-C68uAqGB.mjs";
 import { matchesConcept, requiredFieldsFor, scoreFieldMap, scoreRelationships, suggestCursorField, toFieldMap } from "./internal-entity-heuristics.mjs";
-import { s as isPlaceholderUrl, t as createClivlySDK } from "./sdk-Dkq6ELkf.mjs";
+import { s as isPlaceholderUrl, t as createClivlySDK } from "./sdk-D6gX0TXS.mjs";
 import { createRequire } from "node:module";
 import { spawn } from "node:child_process";
 import { accessSync, constants, existsSync, mkdirSync, readFileSync, readdirSync, realpathSync, statSync, watch, writeFileSync } from "node:fs";
@@ -305,16 +305,27 @@ function addCommand(pm, packages) {
 */
 const CLIVLY_TICK_PATH = "/api/clivly/tick";
 /**
-* What `clivly login` writes into `.env` for `CLIVLY_SYNC_TRIGGER_URL`.
+* The example shape `clivly init`/`clivly login` show for `CLIVLY_SYNC_TRIGGER_URL`
+* — commented out in `.env`, not written as a live value.
 *
-* A visible template beats an empty line: the developer sees the shape they
-* eventually need — a public origin plus the tick path — instead of an unhelpful
-* `CLIVLY_SYNC_TRIGGER_URL=` they have to go and look up.
+* It used to be scaffolded uncommented, on the theory that a visible template
+* beats an empty line. The SDK's `isPlaceholderUrl` guard
+* (`@clivly/sdk/trigger-url`) already keeps a bracketed placeholder like this
+* one out of `syncTrigger.url` on every heartbeat — `resolveTriggerUrl` skips
+* it in favour of the dev tunnel / platform-derived origin — and
+* `assertSafeTriggerUrl` on the API side rejects it outright if it were ever
+* sent, since `<yourDomain.com>` doesn't even parse as a URL. So it was never
+* actually fireable (F-12 is not an SSRF/overwrite bug).
 *
-* It is safe to ship a truthy non-address here only because the SDK refuses to
-* treat a bracketed value as configured (`isPlaceholderUrl` in
-* `@clivly/sdk/trigger-url`). Change the brackets here and that guard stops
-* matching, so the two must stay in step.
+* What it DID break: readiness reporting only checked *presence*, not
+* validity, so an unedited placeholder made the dashboard's setup ladder and
+* `triggerConfigured` report "done" while `clivly status` correctly flagged
+* it — two surfaces disagreeing about a workspace that could never run "Run
+* sync". See `hasWorkingTrigger` (`@clivly.com/api/sync-trigger`) for the
+* fix. Commenting the example out here removes the confusing truthy-but-fake
+* value at the source, on top of that fix, while keeping the shape visible
+* for the (uncommon) case a developer needs it — most platforms are
+* auto-detected, and `clivly dev` handles local development.
 */
 const TRIGGER_URL_PLACEHOLDER = `https://<yourDomain.com>${CLIVLY_TICK_PATH}`;
 //#endregion
@@ -1439,8 +1450,8 @@ function credentialEntries(credentials) {
 		},
 		{
 			key: "CLIVLY_SYNC_TRIGGER_URL",
-			value: TRIGGER_URL_PLACEHOLDER,
-			comment: "Public URL of your tick route — replace <yourDomain.com> once deployed. Local dev: run `clivly dev` instead."
+			value: "",
+			comment: `Public URL of your tick route. Only needed when the platform's own URL can't be auto-detected (see \`clivly status\`). Uncomment and set your deployed origin if so:\n# CLIVLY_SYNC_TRIGGER_URL=${TRIGGER_URL_PLACEHOLDER}`
 		}
 	];
 }
@@ -1809,8 +1820,7 @@ const CLIVLY_ENV_KEYS = [
 	},
 	{
 		key: "CLIVLY_SYNC_TRIGGER_URL",
-		value: TRIGGER_URL_PLACEHOLDER,
-		comment: "Public URL of your tick route — replace <yourDomain.com> once deployed. Local dev: run `clivly dev` instead."
+		comment: `Public URL of your tick route. Only needed when the platform's own URL can't be auto-detected (see \`clivly status\`). Uncomment and set your deployed origin if so:\n# CLIVLY_SYNC_TRIGGER_URL=${TRIGGER_URL_PLACEHOLDER}`
 	},
 	{
 		key: "CLIVLY_SYNC_TRIGGER_SECRET",
@@ -1870,6 +1880,7 @@ function renderImports(plan) {
 		"import { createClivlySDK, defineClivlyConfig } from \"clivly/sdk\";",
 		"import { fromDrizzle } from \"clivly/drizzle\";",
 		"import { discoverFromDrizzle } from \"clivly/drizzle\";",
+		"import { drizzleIntrospector } from \"clivly/drizzle\";",
 		`import * as schema from "${plan.importPath}";`
 	];
 	if (plan.db === null) {
@@ -1902,6 +1913,9 @@ export default createClivlySDK({
   // Every table in your Drizzle schema, so the Clivly dashboard can offer them
   // all when you add a mapping — not just the ones wired up as sources below.
   schema: discoverFromDrizzle(schema),
+  // Lets derived objects authored in the dashboard run against this database.
+  // Without it they are fetched, validated and then skipped.
+  introspector: drizzleIntrospector(${dbExpr}),
   source: {
     // Keyed by CRM concept — contacts/companies/deals/custom.
     // NOT by your entity key. The entity's own \`source:\` above is a table name.
@@ -3200,6 +3214,32 @@ const STATUS_STAGES = [
 		}
 	},
 	sdkChecksStage,
+	{
+		id: "derived-objects",
+		label: "Dashboard-authored objects",
+		needs: [configStage.id],
+		run(ctx) {
+			const remote = ctx.sdk?.describeRemoteProjections?.();
+			if (!remote) return Promise.resolve({
+				state: "skip",
+				detail: "This app's installed clivly predates dashboard-authored objects."
+			});
+			if (!remote.capable) return Promise.resolve({
+				state: "warn",
+				detail: "Objects authored in the dashboard cannot run against this app.",
+				hint: "Add `introspector: drizzleIntrospector(db)` to clivly.config.ts."
+			});
+			if (!remote.ran) return Promise.resolve({
+				state: "pass",
+				detail: "Ready; no sync has run in this process yet."
+			});
+			const broken = remote.invalid + remote.failed;
+			return Promise.resolve({
+				state: broken > 0 ? "warn" : "pass",
+				detail: broken > 0 ? `${remote.ok} running, ${broken} not — open the object in Clivly for the reason.` : `${remote.ok} running.`
+			});
+		}
+	},
 	triggerUrlStage
 ];
 function defaultLoadSdk(path) {
@@ -3253,7 +3293,8 @@ const ALIAS_STAGE_IDS = {
 		"config",
 		"runtime",
 		"boot-hook",
-		"setup-checks"
+		"setup-checks",
+		"derived-objects"
 	],
 	connect: [
 		"api-key",