@@ -0,0 +1,17 @@
+---
+'@objectstack/service-datasource': patch
+---
+
+fix(service-datasource)!: Sync (remote tables, object draft, import, catalog refresh) refuses a managed datasource with the existing `400`, because ADR-0015 §4.2 reserves federation for a datasource whose `schemaMode` is not `managed`
+
+Clause-②: no (narrowing)
+Metadata-protocol: none
+
+<!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, object definition or stored shape is added, removed, renamed or re-shaped, and no exported declaration is removed or narrowed, so there is nothing for `objectstack migrate meta` to rewrite. What changes is the answer four runtime REST doors give a caller who asks them to list, draft, import or catalog the tables of a datasource the platform owns; the remedy is to sync from a datasource declared `external` or `validate-only`, never a rewrite of a package source or a stored row. Objects an earlier import already bound to a managed datasource are not touched. -->
+
+**BREAKING** (four REST doors' accept set narrows). ADR-0015 §1 puts a federated object on a datasource whose `schemaMode` is not `managed`, and §4.2 allows `object.external` only there; `managed` is the spec's default. The Sync doors refused only the platform's primary datasource (`default`). Every other managed datasource answered, including the runtime datasources an administrator creates in Setup → Datasources, which are saved with no `schemaMode` and so are managed: their tables were listed, drafted and imported as federated objects. The engine's write gate (ADR-0015 §5.3) gates only non-managed datasources, so nothing stood behind such an import. One guard in the federation service now refuses before anything is introspected, and every door that reaches the service inherits it.
+
+- **FROM:** on a datasource other than `default` whose `schemaMode` is `managed`, declared or by default, `GET /api/v1/datasources/:name/remote-tables` and `GET /api/v1/datasources/:name/external/tables` answered `200` with its tables; `POST /api/v1/datasources/:name/object-draft` and `POST /api/v1/datasources/:name/external/tables/:remote/draft` answered `200` with a federated object draft bound to it; `POST /api/v1/datasources/:name/external/tables/:remote/import` answered `201` and saved that object; `POST /api/v1/datasources/:name/external/refresh-catalog` answered `200` and stored an `external_catalog` for it. A name with no datasource definition was introspected whenever a driver was registered under it.
+- **TO:** each of those requests answers `400` with the code its door already serves for a refusal, `EXTERNAL_DATASOURCE_ERROR` (the import: `EXTERNAL_IMPORT_ERROR`), and a message naming the rule and the remedy. Nothing is introspected, drafted, saved or stored. A name with no datasource definition gets the same refusal: nothing declares it a federation source.
+- **Unchanged:** `default` keeps its own refusal and message. A datasource declared `schemaMode: 'external'` or `'validate-only'` lists, drafts, imports and refreshes as before. Test (`POST /api/v1/datasources/:name/test`) and validation (`POST /api/v1/datasources/:name/external/validate`) answer as before; validation already skipped a managed datasource, and it now asks the same predicate the guard asks. No status code or error code is added.
+- **The fix for an integrator:** sync from a datasource the platform does not own. Declare it with `schemaMode: 'external'` (or `'validate-only'`) and its `external` settings; for a runtime datasource, send both in `PATCH /api/v1/datasources/:name`. A managed datasource's tables are the platform's own objects: define objects on it directly instead of importing them.
@@ -231,7 +231,7 @@ const makeQl = () => bindTestSecurityCatalog({
 function mountBoth() {
   const service = new ExternalDatasourceService({
     introspect: async () => REMOTE,
-    getDatasource: async (name: string) => ({ name }),
+    getDatasource: async (name: string) => ({ name, schemaMode: 'external' as const }),
     getObject: async () => undefined,
     listObjects: async () => [],
   });
 
@@ -29,7 +29,10 @@
  * The service is asked again at each use, never remembered from the first
  * one. A service registered BEFORE `init()` (the `objectstack dev` ordering)
  * gets the same answers. With no `'metadata'` service at all, every reader
- * keeps its documented fallback.
+ * keeps its documented fallback. [#24837] For the Sync doors that fallback is
+ * now a refusal: with no datasource definition to read, nothing declares the
+ * datasource a federation source (ADR-0015 §4.2), which is also why validate
+ * skips it.
  *
  * [#21889] The namespace half (the draft's prefix and the import's name
  * check) moved to `external-namespace-reads-engine-registry.test.ts`: the
@@ -277,16 +280,29 @@ describe('control: a metadata service registered before init (the dev ordering)
 });
 
 describe('with no metadata service at all, every reader keeps its fallback', () => {
-  it('validate and the sweep answer an empty report, the draft a bare name, the catalog an unpersisted snapshot', async () => {
+  // [#24837] REVERSED. This case held the draft, the catalog refresh and the
+  // remote-table list ANSWERING with no metadata service at all, so with no
+  // datasource definition to read. The Sync doors now refuse that datasource:
+  // nothing declares it a federation source, and ADR-0015 §4.2 reserves
+  // federation for a datasource whose `schemaMode` is not `managed`. It is the
+  // same reading validate already made of an unreadable definition ("not
+  // federated", the empty report below), so an import can no longer bind an
+  // object the sweep would never check. The refusal comes before any
+  // introspection.
+  it('validate and the sweep answer an empty report, and the Sync doors refuse an undeclared datasource', async () => {
     // [#21842] No engine registry either: that is where validate's objects
     // come from, so with neither service the report has nothing to list.
-    const service = await federation(harness({ registry: false }));
+    const h = harness({ registry: false });
+    const service = await federation(h);
 
     expect(await service.validateAll()).toEqual({ ok: true, results: [] });
-    expect((await service.generateObjectDraft('warehouse', 'customers')).name).toBe('customers');
-    const catalog = await service.refreshCatalog('warehouse');
-    expect(catalog.name).toBe('warehouse_catalog');
-    expect((await service.listRemoteTables('warehouse')).map((t) => t.name).sort()).toEqual(['customers', 'orders']);
+    const refusal = { status: 400, message: expect.stringContaining("Datasource 'warehouse' has no datasource definition") };
+    await expect(service.generateObjectDraft('warehouse', 'customers')).rejects.toMatchObject({ code: 'EXTERNAL_DATASOURCE_ERROR', ...refusal });
+    await expect(service.refreshCatalog('warehouse')).rejects.toMatchObject({ code: 'EXTERNAL_DATASOURCE_ERROR', ...refusal });
+    await expect(service.listRemoteTables('warehouse')).rejects.toMatchObject({ code: 'EXTERNAL_DATASOURCE_ERROR', ...refusal });
+    await expect(service.importObject('warehouse', 'customers')).rejects.toMatchObject({ code: 'EXTERNAL_IMPORT_ERROR', ...refusal });
+    const data = h.services.get('data') as { introspectDatasource: Mock };
+    expect(data.introspectDatasource).not.toHaveBeenCalled();
   });
 
   it('a metadata service with no register leaves the catalog unpersisted, without failing the refresh', async () => {