@@ -0,0 +1,83 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec)!: connector-attached sync leaves the connector — `syncConfig` and `fieldMappings` are retired, and a `mapping` gains the `connectorSource` pull binding (#20281)
+
+**BREAKING** — `connector.syncConfig` (the `DataSyncConfig` block: `strategy`,
+`direction`, `realtimeSync`, `timestampField`, `conflictResolution`, `batchSize`,
+`deleteMode`, `filters`) and `connector.fieldMappings` (the `ConnectorFieldMapping`
+list: `source`, `target`, `defaultValue`, `dataType`, `required`, `syncMode`) are
+removed from `ConnectorSchema` and `DeclarativeConnectorEntrySchema` — so from
+`defineConnector`, `stack.connectors[]`, the `PUT /api/v1/meta/connector/:name` door
+and `AutomationEngine.registerConnector`. The `DataSyncConfigSchema`,
+`SyncStrategySchema`, `ConnectorConflictResolutionSchema` and
+`ConnectorFieldMappingSchema` exports (and their `DataSyncConfig`, `SyncStrategy`,
+`ConnectorConflictResolution`, `ConnectorFieldMapping` types and `…Parsed` aliases)
+leave `@objectstack/spec/integration` with them. ADR-0049, ruled ENFORCE on the
+maintainer's criterion for a declared-but-unenforced family, with the definition
+MOVED: every mainstream platform binds a sync to its TARGET, not to the connection.
+
+Measured before removal: no engine ever ran a connector-attached sync or moved a
+value through a connector field mapping — outside the spec package `syncConfig`
+appeared only in two comments and `fieldMappings` nowhere, the automation service's
+declared-connector item carried neither key, and the def a provider registers is its
+own. The `latest_wins` and `soft_delete` defaults read as configured policy and did
+nothing; the platform has no soft delete.
+
+**Added (declared, not yet executed):** `mapping.connectorSource` — the pull
+binding on the target side, beside the mapping's existing `targetObject`,
+`fieldMapping`, `mode` and `upsertKey`: `connector` (a `rest` or `openapi`
+connector instance), `action` (the action that reads the records), optional
+`input`, optional `recordsPath`, and an optional `watermark` (`field` on the
+record, `param` on the request) for a timestamp-incremental pull. Version 1 is a
+one-way pull. It carries no cadence (a `job` sets that), no credential (the
+connector instance holds it) and no delete or conflict policy. Nothing executes it
+in this release, and `os validate` / `os build` warn when it is authored.
+
+### FROM → TO
+
+| removed | what to write instead |
+| --- | --- |
+| `connector.syncConfig` | delete the key. A sync you still want is a `mapping` on its target object, with `connectorSource` naming the connector and its read action, `watermark` for an incremental pull, and a `job` for the cadence. `direction`, `conflictResolution` and `deleteMode` have no counterpart: the pull is one-way and writes through `mode` / `upsertKey`. |
+| `connector.fieldMappings` | delete the key, and carry its `source` → `target` pairs into that mapping's `fieldMapping` (a `defaultValue` becomes a `constant` transform). |
+| `DataSyncConfigSchema`, `SyncStrategySchema`, `ConnectorConflictResolutionSchema`, `ConnectorFieldMappingSchema` and their types | no replacement — nothing parsed a sync or a connector field mapping into anything that ran. |
+
+**The one-line fix: delete `syncConfig:` and `fieldMappings:` from every connector.**
+`os migrate meta --from 17` lists the mechanical edits for existing sources.
+
+⚠️ Runtime behaviour is deliberately **unchanged**: no connector sync ever ran.
+What changes is the answer an author gets — both keys are refused at parse with a
+prescription naming the target-side binding, and in `tsc` (their input type is
+`never`), instead of being saved with no effect.
+
+### The retirement kit
+
+- **Tombstones.** `syncConfig` and `fieldMappings` are `retiredKey()` tombstones on
+  the private `ConnectorBaseSchema` both published carriers wrap (the schema is not
+  `.strict()`, so a bare deletion would be a silent strip, ADR-0104).
+  `RETIRED_KEYS_BY_MAJOR[18]`: `integration/Connector:syncConfig`,
+  `integration/Connector:fieldMappings`,
+  `integration/DeclarativeConnectorEntry:syncConfig` and
+  `integration/DeclarativeConnectorEntry:fieldMappings`. Neither key had a default,
+  so no retired-default residue is owed.
+- **Four defs leave whole** (`RETIRED_DEFS_BY_MAJOR[18]`): `integration/DataSyncConfig`,
+  `integration/SyncStrategy`, `integration/ConnectorConflictResolution`,
+  `integration/ConnectorFieldMapping`. The two `RENAMED_DEFS` entries that targeted
+  them left the rename table.
+- **D2 conversion `connector-sync-keys-removed`** (step 18, retired from the load
+  path): strips both keys from `connectors[]` and from stored `sys_metadata`
+  connector rows (the rehydration seam replays it), one notice per key, as a
+  lossless delete. It never writes a `mapping`: a pulled mapping would start writes
+  that never happened.
+- **D3 entry `connector-sync-keys-retired`** carries the family's judgement: which
+  syncs should now exist as target-side mappings, and what an author who relied on
+  `export`, `bidirectional`, `soft_delete` or a conflict policy does without them.
+- **No deprecation window**, per the project's startup-stage posture.
+
+⚠️ **The out-of-repo consumer population is NOT MEASURED.** `@objectstack/spec` is
+published, so this is breaking for consumers no telemetry was consulted for.
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: registered connector-sync-keys-removed, connector-sync-keys-retired -->
@@ -0,0 +1,33 @@
+---
+"@objectstack/objectql": minor
+"@objectstack/spec": minor
+"@objectstack/lint": patch
+"@objectstack/service-analytics": patch
+---
+
+fix(objectql,spec)!: a `groupBy` on a multi-value field and a `count_distinct` on a JSON-stored field are refused with `INVALID_FIELD` / 400 at the engine's `aggregate`, on every driver, and the aggregate × field-type table stops accepting `count_distinct` over the JSON-stored types
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (already-registered dataset-measure-aggregate-field-type-refused) the one metadata-facing half of this change is a row of AGGREGATE_FIELD_TYPE_COMPATIBILITY narrowing, and that family's hand-migration is already registered under protocol major 18 by this id: "an aggregate the field's type accepts, per AGGREGATE_FIELD_TYPE_COMPATIBILITY", with every refused pair of the table refused at the compile door. The non-temporal sum / avg narrowing rode the same id the same way; this diff amends that entry's surface and acceptance prose to name the count_distinct rider, and corrects the min / max entry's route that called count_distinct valid over every type. The engine-door halves refuse a query shape, not a stored one: no authorable key, export or stored row moves. -->
+
+**BREAKING** (`@objectstack/objectql`): this narrows what `aggregate` accepts, in two positions, on every driver and for every caller that reaches the engine (the REST query door, a flow or hook, and the analytics strategy that lowers a cube query onto `engine.aggregate`). Shipped as `minor` under the launch-window convention for accept-set narrowings. No export or published type changes.
+
+- A `groupBy` entry that names a **multi-value** field: an inherently-multi option type (`multiselect`, `checkboxes`, `tags`), or a `select`, `lookup`, `user`, `file` or `image` field declared `multiple: true`. Both entry spellings are judged, the field name and the `{ field }` object.
+- A `count_distinct` aggregation over a **JSON-stored** field: a structured-JSON type (`json`, `composite`, `repeater`, `record`, `location`, `address`, `vector`), an inherently-multi option type, or a multi-capable field declared `multiple: true`.
+
+**BREAKING** (`@objectstack/spec`): `AGGREGATE_FIELD_TYPE_COMPATIBILITY.count_distinct` no longer lists the ten JSON-stored types (the structured-JSON seven and `multiselect`, `checkboxes`, `tags`), so `isAggregateCompatibleWithFieldType('count_distinct', type)` answers `false` for them. Every reader of the table refuses those pairs now: the dataset-measure lint rule (`measure-aggregate-field-type-refused`, run by `os validate` and at a runtime dataset save), the analytics dataset compile leg (`400 DATASET_INVALID`), and the engine door above. The `count` row is unchanged.
+
+**What an author sees now.** `400 INVALID_FIELD`, naming the position (`groupBy[0]`, `groupBy[0].field`, or `aggregations[0].field`), the field and its declaration, saying the query was not run, and naming the route inside the first 500 characters the REST door keeps. For a multi-value field the route is to filter by one member: `where` with `$contains` on the field, one query per member. For a structured-JSON field it is to store the part you count in a field of its own, or to count rows with `count`. The thrown error carries `field`, `fields`, `object` and `param` (`groupBy` or `aggregations`).
+
+**Why a refusal.** Every SQL driver stores these values in a JSON column, and the drivers share no meaning for one as a group key or a distinct key. Measured through `POST /api/v1/data/:object/query` over three rows: grouping by any of the eight multi-value declarations answered one group per array on the in-memory driver, one group per serialized array on SQLite, and 500 `DATABASE_ERROR` on PostgreSQL 16. `count_distinct` over any structured-JSON or multi-value field answered 3 on the in-memory driver (equal values counted apart), 2 on SQLite (serialized text compared), and 500 on PostgreSQL (no equality operator for `json`). No example app and no published stack groups by a multi-value field or counts one distinct, so no meaning is defined for either here.
+
+**What to write instead.** A dataset measure or a query that counted a JSON-stored field distinct: use `count` over it, or store the scalar part you meant to count in a field of its own and `count_distinct` that field. A grouping by a multi-value field: filter by each member with `$contains` and count.
+
+**Who is affected.** A caller that grouped by a multi-value field, or counted a JSON-stored field distinct, on the in-memory driver or on SQLite and read the answer as a real one; on PostgreSQL both were already a 500. A dataset whose measure pairs `count_distinct` with a JSON-stored field is refused by the lint rule and the compile leg.
+
+**Unchanged.** (Two shapes the structured-JSON `groupBy` entry of this same release lists as unchanged are narrowed here: a `multiple: true` select as a group key, and `count_distinct` over a structured-JSON field. This entry is the later word on both.) A `groupBy` or `count_distinct` on a scalar-stored field, a single-value `select` or `lookup` included; `count` over any field; the `having`, filter and sort positions; and an undeclared name, which the REST door answers `INVALID_FIELD` as unknown before the engine is reached.
+
+`@objectstack/lint`: the dataset-measure refusal's hint no longer says `count_distinct` accepts every type.
+
+`@objectstack/service-analytics`: the dataset compile leg's refusal of a `count_distinct` measure over a JSON-stored field says why it diverges (the drivers compare the values for equality three ways) and prescribes `count`, or a scalar field for the part being counted; its other refusals no longer say `count_distinct` accepts every type.
@@ -0,0 +1,29 @@
+---
+'@objectstack/cli': patch
+---
+
+fix(cli): `os package publish` sends `visibility` only when `--visibility` is passed, so re-publishing no longer moves a `marketplace` package to `org`
+
+Clause-②: no
+
+The `--visibility` flag defaulted to `org`, and the CLI always sent it in the package
+upsert (`POST /api/v1/cloud/packages`). That upsert is also the re-publish path, and
+the control plane updates an existing package's visibility whenever the request carries
+one. So re-publishing a new version of a `marketplace` package without repeating
+`--visibility marketplace` silently set it to `org` and took it out of the marketplace.
+
+The flag no longer has a default, and an omitted flag is an omitted key:
+
+- **Re-publish without the flag:** the package keeps its current visibility.
+- **First publish without the flag:** the control plane applies its own default
+  (`org` on ObjectStack Cloud), so a new package gets the same visibility as before.
+- **With the flag:** unchanged. `--visibility private|org|marketplace` is sent and
+  applied, as before.
+
+The publish summary's `Visibility` line shows the control plane's answer. When the
+control plane does not report it and no flag was given, the line says
+`not reported by the control plane`. The "visibility is marketplace but the version is
+still draft" hint now follows that answer too, so it also fires when a `marketplace`
+package is re-published without the flag. The `--submit` help text now states its
+precondition as the package's visibility being `marketplace` (already stored, or set
+with `--visibility marketplace`), since the flag is no longer sent on every publish.
@@ -2061,13 +2061,13 @@ when both files' `url`s agree.
 | `--display-name <name>` | — | Name shown in the Marketplace (default `artifact.manifest.name`) |
 | `--description <text>` | — | Short package description |
 | `--category <slug>` | — | Marketplace category slug (`crm`, `hr`, `devtools`, …) |
-| `--visibility <level>` | — | `org` (default, installable across your organization) · `private` (explicit grants only) · `marketplace` (public after review) |
+| `--visibility <level>` | — | `org` (installable across your organization) · `private` (explicit grants only) · `marketplace` (public after review). Omitted: not sent, so the control plane decides — an existing package keeps its visibility, a new one gets the control plane's default (`org` on ObjectStack Cloud) |
 | `--org <id>` | `OS_ORG_ID` | `owner_org_id`. Required with a bearer key in service mode; ignored in user mode |
 | `--env <id>` | `OS_ENVIRONMENT_ID` | Environment to install the new version into. Defaults to the environment [`os environments switch`](#cloud-environments) — or `os environments create --activate` — recorded **for this control plane** in `~/.objectstack/cloud.json` |
 | `--install` | — | Auto-install into `--env` after publishing. With no `--env`, no `$OS_ENVIRONMENT_ID` and no active environment for this control plane, it reports that and publishes without installing |
 | `--seed-sample-data` | — | Include sample data in that auto-install |
 | `--pre-release` | — | Mark the version as a pre-release (also inferred — see below) |
-| `--submit` | — | Submit the new version for marketplace review. Needs `--visibility marketplace` and a complete listing |
+| `--submit` | — | Submit the new version for marketplace review. Needs the package's visibility to be `marketplace` (already stored, or set with `--visibility marketplace`) and a complete listing |
 | `--auto-approve` | — | Platform admin only: skip the review queue and publish straight to the public catalog |
 | `--readme <markdown>` | — | Inline marketplace README. Mutually exclusive with `--readme-file` |
 | `--readme-file <path>` | — | README file, read at publish time. Mutually exclusive with `--readme` |
 
@@ -165,7 +165,7 @@ Common flags:
 | `--server`, `-s` | `OS_CLOUD_URL` | Cloud control-plane URL |
 | `--token`, `-t` | `OS_CLOUD_API_KEY` | Bearer token (service mode) |
 | `--version`, `-v` | — | Semver version (default: `artifact.manifest.version`) |
-| `--visibility` | — | `org` (default) · `private` · `marketplace` |
+| `--visibility` | — | `org` · `private` · `marketplace`. Omitted: the control plane decides — an existing package keeps its visibility, a new one gets its default (`org` on ObjectStack Cloud) |
 | `--org` | `OS_ORG_ID` | Owner org id (service mode) |
 | `--env` | `OS_ENVIRONMENT_ID` | Environment to install the new version into. Defaults to the environment `os environments switch` (or `os environments create --activate`) recorded for this control plane in `~/.objectstack/cloud.json` |
 | `--install` | — | Auto-install the new version into `--env` after publishing |
 
@@ -206,9 +206,11 @@ measures: [{ name: 'avg_closed', aggregate: 'avg', field: 'closed_at' }]
 `avg` over a temporal column is where this bites hardest: one SQL family coerces
 the stored text and returns a plausible number (the average *year*), another has
 no such function and fails at query time. `min`/`max` over the same field are
-**accepted** — they return a real instant of the field's own type — and
-`count`/`count_distinct` are accepted over every type, because they read no
-arithmetic off the value. The analytics service refuses the same pair with
+**accepted** — they return a real instant of the field's own type — `count` is
+accepted over every type, because it reads no value, and `count_distinct` over
+every type but the JSON-stored ones (the structured-JSON types and
+`multiselect` / `checkboxes` / `tags`), whose values no two backends compare
+for equality alike. The analytics service refuses the same pair with
 `400 DATASET_INVALID` when a query is built; this is the identical verdict,
 from the identical table, one door earlier. The rule stays silent wherever the
 field's type cannot be resolved (an object this stack does not define, a
 
@@ -49,6 +49,7 @@ const result = ImportFieldMappingSchema.parse(data);
 | **fieldMapping** | `{ source: string \| string[]; target: string \| string[]; transform: Enum<'none' \| 'constant' \| 'lookup' \| 'split' \| 'join' \| 'javascript' \| 'map'>; params?: object }[]` | ✅ |  |
 | **mode** | `Enum<'insert' \| 'update' \| 'upsert'>` | optional (default: `"insert"`) |  |
 | **upsertKey** | `string[]` | optional | Fields to match for upsert (e.g. email) |
+| **connectorSource** | `{ connector: string; action: string; input?: Record<string, any>; recordsPath?: string; … }` | optional | Pull binding: the rest/openapi connector this mapping pulls rows from (one-way, full or timestamp-incremental; a `job` sets the cadence). Declared; the pull is not executed yet |
 | **_lock** | `Enum<'none' \| 'no-overlay' \| 'no-delete' \| 'full'>` | optional | Item-level lock — controls overlay & delete (ADR-0010). |
 | **_lockReason** | `string` | optional | Human-readable reason shown when a write is refused by _lock. |
 | **_lockSource** | `Enum<'artifact' \| 'package' \| 'env-forced'>` | optional | Layer that set _lock (artifact \| package \| env-forced). |
@@ -66,6 +67,16 @@ const result = ImportFieldMappingSchema.parse(data);
 | **transform** | `Enum<'none' \| 'constant' \| 'lookup' \| 'split' \| 'join' \| 'javascript' \| 'map'>` | optional (default: `"none"`) |  |
 | **params** | `{ value?: any; valueMap?: Record<string, any>; separator?: string }` | optional |  |
 
+### Nested Shape: `Mapping.connectorSource`
+
+| Property | Type | Required | Description |
+| :--- | :--- | :--- | :--- |
+| **connector** | `string` | ✅ | Name of the connector instance the rows are pulled from — a `connectors[]` entry whose `provider` is `rest` or `openapi` (version 1) |
+| **action** | `string` | ✅ | Key of the connector action that reads the records: `request` on a `rest` connector, an operation key on an `openapi` connector |
+| **input** | `Record<string, any>` | optional | Fixed input passed to the action on every pull (e.g. `{ method: 'GET', path: '/contacts' }` for `rest`) |
+| **recordsPath** | `string` | optional | Dot path, within the action's result, to the array of records (e.g. `body.results`); omitted ⇒ the result's `body` is the array |
+| **watermark** | `{ field: string; param: string }` | optional | Timestamp-incremental pull; omitted ⇒ every pull reads the full set |
+
 
 ---