@mcp-abap-adt/connection 5.0.0 → 6.0.1

package/dist/connection/connectionFactory.js

@@ -1,84 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.createAbapConnection = createAbapConnection;
-const providers_js_1 = require("../auth/providers.js");
-const AdtCloudConnector_js_1 = require("./AdtCloudConnector.js");
-const AdtOnPremConnector_js_1 = require("./AdtOnPremConnector.js");
-const BaseAbapConnection_js_1 = require("./BaseAbapConnection.js");
-const CertificateAbapConnection_js_1 = require("./CertificateAbapConnection.js");
-const JwtAbapConnection_js_1 = require("./JwtAbapConnection.js");
-const KerberosAbapConnection_js_1 = require("./KerberosAbapConnection.js");
-const RfcAbapConnection_js_1 = require("./RfcAbapConnection.js");
-const SamlAbapConnection_js_1 = require("./SamlAbapConnection.js");
-/**
- * The provider for the credential this config carries.
- *
- * Reading `authType` here is not the thing the split removed: it says HOW to
- * authenticate, which is what it always meant. What it no longer does is decide
- * which system this is — the caller said that.
- */
-function authProviderFor(config, options, tokenRefresher) {
-    switch (config.authType) {
-        case 'jwt':
-            // No longer refused. It was, while renewal lived only in
-            // JwtAbapConnection and this path would have handed back a connection
-            // that died on the first expiry. The connector now tells the provider
-            // when a token was rejected and rebuilds the session behind it, so a
-            // refresher passed here is used for what it is for.
-            return new providers_js_1.TokenAuthProvider(tokenRefresher ?? config.jwtToken ?? '');
-        case 'saml':
-            return new providers_js_1.SamlAuthProvider(config.sessionCookies ?? '');
-        case 'certificate':
-            if (!options.certLoader) {
-                throw new Error('authType "certificate" needs options.certLoader to load the material.');
-            }
-            return new providers_js_1.CertificateAuthProvider(options.certLoader, config);
-        case 'basic':
-            return new providers_js_1.BasicAuthProvider(config.username ?? '', config.password ?? '');
-        default:
-            throw new Error(`authType "${config.authType}" has no auth provider yet; use the deprecated class for it.`);
-    }
-}
-/**
- * Builds the connection the caller asked for.
- *
- * **Say which system it is** with `options.system`, and that is what you get —
- * `'onprem'` or `'cloud'` — with the credential built from the config and
- * handed in as an auth provider. Nothing about the system is worked out here:
- * not from the credential, not from the host name, not by asking the server.
- *
- * Without it, the old behaviour: a connection chosen from `authType`, which is
- * the arrangement where the credential drags the session mechanism along with
- * it and gets one of them wrong. **Deprecated**, kept so existing callers keep
- * working, and warned about once per call so it is visible rather than
- * inherited by accident.
- */
-function createAbapConnection(config, logger, sessionId, tokenRefresher, options) {
-    // RFC connection type takes priority over auth type
-    if (config.connectionType === 'rfc') {
-        if (config.authType === 'certificate' || config.authType === 'kerberos') {
-            throw new Error(`authType "${config.authType}" is not supported with connectionType "rfc".`);
-        }
-        return new RfcAbapConnection_js_1.RfcAbapConnection(config, logger);
-    }
-    if (options?.system) {
-        const provider = authProviderFor(config, options, tokenRefresher);
-        const Connector = options.system === 'cloud' ? AdtCloudConnector_js_1.AdtCloudConnector : AdtOnPremConnector_js_1.AdtOnPremConnector;
-        return new Connector(config, provider, logger ?? null, sessionId, options);
-    }
-    logger?.warn("createAbapConnection(): no options.system given, so the connection is chosen from authType — which lets the credential decide the session mechanism. Pass system: 'onprem' | 'cloud'.");
-    switch (config.authType) {
-        case 'basic':
-            return new BaseAbapConnection_js_1.BaseAbapConnection(config, logger, sessionId, options);
-        case 'jwt':
-            return new JwtAbapConnection_js_1.JwtAbapConnection(config, logger, sessionId, tokenRefresher);
-        case 'saml':
-            return new SamlAbapConnection_js_1.SamlAbapConnection(config, logger, sessionId, options);
-        case 'certificate':
-            return new CertificateAbapConnection_js_1.CertificateAbapConnection(config, logger, sessionId, options?.certLoader);
-        case 'kerberos':
-            return new KerberosAbapConnection_js_1.KerberosAbapConnection(config, logger, sessionId);
-        default:
-            throw new Error(`Unsupported SAP authentication type: ${config.authType}`);
-    }
-}

package/dist/session/CloudSecuritySessionStrategy.d.ts

@@ -1,32 +0,0 @@
-/**
- * ABAP Cloud: a session is a resource, asked for and given back by address.
- *
- * Captured from Eclipse ADT 3.60 against a BTP trial and reproduced here with a
- * bearer token, which is what made the difference visible: **the server issues
- * `SAP_SESSIONID` to whoever asks for a session, and we never asked.** The
- * request that asks carries `x-sap-security-session: create` — `use` does not
- * do it — and `sap-adt-purpose: preflight_logon`. The response sets the cookie
- * and publishes the session's own address in a `securitysession` link, which is
- * the address a close goes to.
- *
- * Without that request the same connection gets `sap-usercontext` and
- * `sap-XSRF_*` and nothing else, no `securitysession` link, and no session for
- * a lock to be bound to — which is how "cloud does not issue SAP_SESSIONID"
- * came to be believed.
- */
-import { type ISessionTransport, SessionStrategy } from './SessionStrategy.js';
-export declare class CloudSecuritySessionStrategy extends SessionStrategy {
-    readonly kind: "cloud-security-session";
-    /** The address this server published for our session — the only close target. */
-    private resource;
-    openSession(transport: ISessionTransport): Promise<boolean>;
-    closeSession(transport: ISessionTransport): Promise<void>;
-    /**
-     * The `securitysession` link's href, by its `rel` rather than by position.
-     *
-     * The document carries three links — the session, the logoff resource and
-     * system information — and their order is not a contract.
-     */
-    private securitySessionHref;
-}
-//# sourceMappingURL=CloudSecuritySessionStrategy.d.ts.map

package/dist/session/CloudSecuritySessionStrategy.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"CloudSecuritySessionStrategy.d.ts","sourceRoot":"","sources":["../../src/session/CloudSecuritySessionStrategy.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAIH,OAAO,EAAE,KAAK,iBAAiB,EAAE,eAAe,EAAE,MAAM,sBAAsB,CAAC;AAa/E,qBAAa,4BAA6B,SAAQ,eAAe;IAC/D,QAAQ,CAAC,IAAI,EAAG,wBAAwB,CAAU;IAElD,iFAAiF;IACjF,OAAO,CAAC,QAAQ,CAAuB;IAEjC,WAAW,CAAC,SAAS,EAAE,iBAAiB,GAAG,OAAO,CAAC,OAAO,CAAC;IA6D3D,YAAY,CAAC,SAAS,EAAE,iBAAiB,GAAG,OAAO,CAAC,IAAI,CAAC;IAoC/D;;;;;OAKG;IACH,OAAO,CAAC,mBAAmB;CAW5B"}

package/dist/session/IcfSessionStrategy.d.ts

@@ -1,27 +0,0 @@
-/**
- * On-prem: the logon is the establishing request, and the platform takes the
- * session back through `/sap/public/bc/icf/logoff`.
- *
- * There is nothing to open. The session arrives as a `SAP_SESSIONID` cookie on
- * the establishing call, which is why on-prem SM04 shows those sessions opened
- * by `P=/sap/bc/adt/discovery` — one per `connect()`, and one left behind per
- * `connect()` that never said it was finished.
- *
- * ADT publishes no session resource here — `/sap/bc/adt/core/http/sessions`
- * does not exist — so this is the only mechanism, and it is the platform's
- * rather than ADT's.
- */
-import { type ISessionTransport, SessionStrategy } from './SessionStrategy.js';
-export declare class IcfSessionStrategy extends SessionStrategy {
-    readonly kind: "icf";
-    /**
-     * Nothing to ask for: the session comes with the establishing request.
-     *
-     * `false` is about the session RESOURCE, not about sessions — this system has
-     * no address to open or close one by, which is exactly why the close below is
-     * the platform's logoff.
-     */
-    openSession(_transport: ISessionTransport): Promise<boolean>;
-    closeSession(transport: ISessionTransport): Promise<void>;
-}
-//# sourceMappingURL=IcfSessionStrategy.d.ts.map

package/dist/session/IcfSessionStrategy.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"IcfSessionStrategy.d.ts","sourceRoot":"","sources":["../../src/session/IcfSessionStrategy.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAGH,OAAO,EAAE,KAAK,iBAAiB,EAAE,eAAe,EAAE,MAAM,sBAAsB,CAAC;AAI/E,qBAAa,kBAAmB,SAAQ,eAAe;IACrD,QAAQ,CAAC,IAAI,EAAG,KAAK,CAAU;IAE/B;;;;;;OAMG;IACG,WAAW,CAAC,UAAU,EAAE,iBAAiB,GAAG,OAAO,CAAC,OAAO,CAAC;IAI5D,YAAY,CAAC,SAAS,EAAE,iBAAiB,GAAG,OAAO,CAAC,IAAI,CAAC;CA+BhE"}

package/dist/session/IcfSessionStrategy.js

@@ -1,62 +0,0 @@
-"use strict";
-/**
- * On-prem: the logon is the establishing request, and the platform takes the
- * session back through `/sap/public/bc/icf/logoff`.
- *
- * There is nothing to open. The session arrives as a `SAP_SESSIONID` cookie on
- * the establishing call, which is why on-prem SM04 shows those sessions opened
- * by `P=/sap/bc/adt/discovery` — one per `connect()`, and one left behind per
- * `connect()` that never said it was finished.
- *
- * ADT publishes no session resource here — `/sap/bc/adt/core/http/sessions`
- * does not exist — so this is the only mechanism, and it is the platform's
- * rather than ADT's.
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.IcfSessionStrategy = void 0;
-const cookies_js_1 = require("../utils/cookies.js");
-const SessionStrategy_js_1 = require("./SessionStrategy.js");
-const ICF_LOGOFF_PATH = '/sap/public/bc/icf/logoff';
-class IcfSessionStrategy extends SessionStrategy_js_1.SessionStrategy {
-    kind = 'icf';
-    /**
-     * Nothing to ask for: the session comes with the establishing request.
-     *
-     * `false` is about the session RESOURCE, not about sessions — this system has
-     * no address to open or close one by, which is exactly why the close below is
-     * the platform's logoff.
-     */
-    async openSession(_transport) {
-        return false;
-    }
-    async closeSession(transport) {
-        const cookies = transport.cookies();
-        if (!cookies) {
-            // Holding the cookie is the whole permission to end a session, and it is
-            // why nothing is sent without one. The session limit is per user and the
-            // pool is shared — a SAP GUI logon of the same user sits in the same SM04
-            // list — so a connector that tidied up sessions it did not open would
-            // eventually close somebody's GUI.
-            return;
-        }
-        try {
-            // Read once: see CloudSecuritySessionStrategy — a provider may answer
-            // differently on a second call, and one request must be built from one
-            // credential.
-            const auth = await transport.authHeaders();
-            await transport.send({
-                method: 'GET',
-                url: `${transport.baseUrl}${ICF_LOGOFF_PATH}`,
-                headers: {
-                    ...auth,
-                    Cookie: (0, cookies_js_1.mergeCookieHeaders)(auth.Cookie, cookies),
-                },
-            });
-            this.logger?.debug('Told the server the session is finished');
-        }
-        catch (error) {
-            this.logger?.debug(`Could not tell the server the session is finished: ${error instanceof Error ? error.message : String(error)}`);
-        }
-    }
-}
-exports.IcfSessionStrategy = IcfSessionStrategy;

package/dist/session/SessionStrategy.d.ts

@@ -1,86 +0,0 @@
-/**
- * How a session is opened on the server, and how the server is told we are
- * done with it.
- *
- * Two systems, two mechanisms, one meaning. On ABAP Cloud a session is a
- * resource: it is asked for at `/sap/bc/adt/core/http/sessions` and the
- * response publishes its own address, which is what a `DELETE` is sent to. On
- * on-prem there is no such resource — the logon call is the establishing
- * request itself, and the platform's `/sap/public/bc/icf/logoff` is how it is
- * given back.
- *
- * **Both are notifications, not commands.** They say "we have finished with
- * this session". Whether the system frees it now, later, or keeps it to reuse
- * is the system's business, and nothing here checks afterwards or depends on
- * the answer. Measured on a trial: the `DELETE` is answered `200` and the
- * session is still listed a moment later; the logoff is answered `200` and it
- * is not. Neither is a failure — they are two systems deciding differently
- * about a message they both accepted.
- *
- * Split by what the server publishes rather than by which system we think we
- * are talking to: `openSession()` asks, and a system that has no such resource
- * says so. Guessing the platform would be a guess; asking is not.
- */
-import type { ILogger } from '../logger.js';
-/** What a strategy needs from the connection to talk to the server. */
-export interface ISessionTransport {
-    /** Absolute base URL of the system. */
-    baseUrl: string;
-    /** Auth headers for a request made outside the normal request path. */
-    authHeaders(): Promise<Record<string, string>>;
-    /** Cookies held for this connection, or null before any have arrived. */
-    cookies(): string | null;
-    /** The CSRF token held, if one has been fetched. */
-    csrfToken(): string | null;
-    /** Issue a raw request and hand back status, headers and body. */
-    send(request: {
-        method: 'GET' | 'DELETE';
-        url: string;
-        headers: Record<string, string>;
-        /**
-         * A deadline for the REQUEST, and only where one belongs.
-         *
-         * The open is a preflight that `connect()` waits for, so it is bounded.
-         * The close must not be: a request timeout aborts the socket, which would
-         * cancel the very message it was waiting for and leave the session open —
-         * the caller's own deadline bounds the WAIT instead, elsewhere.
-         */
-        timeoutMs?: number;
-        /**
-         * Whether the cookies this answers with become the connection's.
-         *
-         * True for the open — its `SAP_SESSIONID` **is** the session. False for a
-         * close: a teardown's response must not feed the session identity, or the
-         * cookies it sets read as the session having been replaced under a
-         * connection that is on its way out.
-         */
-        adoptCookies?: boolean;
-    }): Promise<{
-        status: number;
-        headers: unknown;
-        data: unknown;
-    }>;
-}
-export declare abstract class SessionStrategy {
-    protected readonly logger: ILogger | null;
-    constructor(logger: ILogger | null);
-    /** A name for logs, so which one ran is never a guess. */
-    abstract readonly kind: 'cloud-security-session' | 'icf';
-    /**
-     * Ask the server to open a session, before anything needs one.
-     *
-     * Returns whether a session resource was actually opened and its address
-     * captured — `false` is not a failure, it is a system saying it has none, and
-     * the close then falls to the mechanism that needs no address. Never throws: a system that
-     * will not open one is a fact for the establishment that follows to report,
-     * with the whole picture, not a transport error raised from a preflight.
-     */
-    abstract openSession(transport: ISessionTransport): Promise<boolean>;
-    /**
-     * Tell the server we are done with the session.
-     *
-     * Never throws, and says nothing about what the server then did with it.
-     */
-    abstract closeSession(transport: ISessionTransport): Promise<void>;
-}
-//# sourceMappingURL=SessionStrategy.d.ts.map

package/dist/session/SessionStrategy.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"SessionStrategy.d.ts","sourceRoot":"","sources":["../../src/session/SessionStrategy.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,cAAc,CAAC;AAE5C,uEAAuE;AACvE,MAAM,WAAW,iBAAiB;IAChC,uCAAuC;IACvC,OAAO,EAAE,MAAM,CAAC;IAChB,uEAAuE;IACvE,WAAW,IAAI,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;IAC/C,yEAAyE;IACzE,OAAO,IAAI,MAAM,GAAG,IAAI,CAAC;IACzB,oDAAoD;IACpD,SAAS,IAAI,MAAM,GAAG,IAAI,CAAC;IAC3B,kEAAkE;IAClE,IAAI,CAAC,OAAO,EAAE;QACZ,MAAM,EAAE,KAAK,GAAG,QAAQ,CAAC;QACzB,GAAG,EAAE,MAAM,CAAC;QACZ,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;QAChC;;;;;;;WAOG;QACH,SAAS,CAAC,EAAE,MAAM,CAAC;QACnB;;;;;;;WAOG;QACH,YAAY,CAAC,EAAE,OAAO,CAAC;KACxB,GAAG,OAAO,CAAC;QAAE,MAAM,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,OAAO,CAAC;QAAC,IAAI,EAAE,OAAO,CAAA;KAAE,CAAC,CAAC;CAClE;AAED,8BAAsB,eAAe;IACvB,SAAS,CAAC,QAAQ,CAAC,MAAM,EAAE,OAAO,GAAG,IAAI;gBAAtB,MAAM,EAAE,OAAO,GAAG,IAAI;IAErD,0DAA0D;IAC1D,QAAQ,CAAC,QAAQ,CAAC,IAAI,EAAE,wBAAwB,GAAG,KAAK,CAAC;IAEzD;;;;;;;;OAQG;IACH,QAAQ,CAAC,WAAW,CAAC,SAAS,EAAE,iBAAiB,GAAG,OAAO,CAAC,OAAO,CAAC;IAEpE;;;;OAIG;IACH,QAAQ,CAAC,YAAY,CAAC,SAAS,EAAE,iBAAiB,GAAG,OAAO,CAAC,IAAI,CAAC;CACnE"}

package/dist/session/SessionStrategy.js

@@ -1,33 +0,0 @@
-"use strict";
-/**
- * How a session is opened on the server, and how the server is told we are
- * done with it.
- *
- * Two systems, two mechanisms, one meaning. On ABAP Cloud a session is a
- * resource: it is asked for at `/sap/bc/adt/core/http/sessions` and the
- * response publishes its own address, which is what a `DELETE` is sent to. On
- * on-prem there is no such resource — the logon call is the establishing
- * request itself, and the platform's `/sap/public/bc/icf/logoff` is how it is
- * given back.
- *
- * **Both are notifications, not commands.** They say "we have finished with
- * this session". Whether the system frees it now, later, or keeps it to reuse
- * is the system's business, and nothing here checks afterwards or depends on
- * the answer. Measured on a trial: the `DELETE` is answered `200` and the
- * session is still listed a moment later; the logoff is answered `200` and it
- * is not. Neither is a failure — they are two systems deciding differently
- * about a message they both accepted.
- *
- * Split by what the server publishes rather than by which system we think we
- * are talking to: `openSession()` asks, and a system that has no such resource
- * says so. Guessing the platform would be a guess; asking is not.
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.SessionStrategy = void 0;
-class SessionStrategy {
-    logger;
-    constructor(logger) {
-        this.logger = logger;
-    }
-}
-exports.SessionStrategy = SessionStrategy;

package/docs/superpowers/specs/2026-08-21-platform-connectors.md

@@ -1,108 +0,0 @@
-# Two connectors, one credential contract
-
-**Status:** draft, for review
-**Subject:** `AdtOnPremConnector` / `AdtCloudConnector` over a shared base, with authentication passed in rather than inherited.
-
-## Why
-
-The class you take today states your **credential**, and the session mechanism rides along with it. `JwtAbapConnection` is the only class that overrides `createSessionStrategy()`, so:
-
-| the consumer builds | on a **cloud** host | on an **on-prem** host |
-|---|---|---|
-| `authType: 'jwt'` | ADT session resource — correct | ADT session resource — wrong |
-| `authType: 'basic'` | ICF logoff — wrong | ICF logoff — correct |
-| `authType: 'saml'` | ICF logoff — wrong | correct |
-| `authType: 'certificate'`, `'kerberos'` | ICF logoff — wrong | correct |
-
-Both wrong rows are reachable. The cloud trial answers `www-authenticate: Basic`, so a communication user against ABAP Cloud is an ordinary setup; SAML is the usual interactive logon on BTP. And the mirror — JWT against an on-prem system — puts that system on a mechanism it does not use.
-
-**The consumer knows which system it is dialling.** It should say so by taking the connector for it, and the credential should be a parameter of that choice rather than the thing making it.
-
-### Why not detect it
-
-Tried, measured, wrong. `/sap/bc/adt/core/http/sessions` was probed to decide the mechanism; **on-prem answers it too** — 200, a `SAP_SESSIONID`, and a document publishing *both* the session resource and `/sap/public/bc/icf/logoff`. The probe never told the two systems apart; it told whether an endpoint exists, and both have it, so on-prem was silently moved onto the cloud mechanism.
-
-Nothing here goes back to asking the server which kind of system it is.
-
-## The shape
-
-```
-AbstractAbapConnection            requests, CSRF, cookies, session lifecycle, admission
-        │
-        ├── AdtOnPremConnector    session arrives with the establishing call;
-        │                         given back with the platform's ICF logoff
-        │
-        └── AdtCloudConnector     session opened at /sap/bc/adt/core/http/sessions
-                                  (`x-sap-security-session: create`,
-                                   `sap-adt-purpose: preflight_logon`);
-                                  given back by DELETE on the address it published
-```
-
-Both take a **credential** object. The two session strategies already exist and do not change; what changes is who chooses them and how authentication arrives.
-
-## The credential contract
-
-`ITokenRefresher` and `ITokenProvider` already exist in `@mcp-abap-adt/interfaces` — the first says outright *"Created by AuthBroker for a specific destination. Injected into JwtAbapConnection to enable automatic token refresh."* — and `@mcp-abap-adt/auth-providers` ships twelve implementations. That is the seam to join, not to reinvent.
-
-But both are about **tokens**, and only one of the five ways in works that way. Measured, every current class overrides exactly two members, plus a few extras:
-
-| | `buildAuthorizationHeader` | `establishSession` | other |
-|---|---|---|---|
-| basic | ✓ | ✓ | — |
-| jwt | ✓ | ✓ | `prepareCredential`, `ensureToken` |
-| saml | ✓ | ✓ | — |
-| certificate | ✓ | ✓ | `getHttpsAgentOptions`, `ensureMaterial` |
-| kerberos | ✓ | ✓ | `fetchCsrfToken` |
-
-So the contract is small and is **not** "give me a token":
-
-```ts
-interface IAbapCredential {
-  /** Prepare before anything is sent — mint, load, unlock. Optional. */
-  prepare?(): Promise<void>;
-  /** The Authorization header value, or '' when the credential is not a header. */
-  authorizationHeader(): string;
-  /** TLS material, for credentials that are a certificate rather than a header. */
-  httpsAgentOptions?(): AgentOptions;
-}
-```
-
-A token provider becomes one implementation of it, wrapping `ITokenRefresher`. Basic wraps a username and password. Certificate returns no header and supplies agent options instead.
-
-**Where it lives:** `@mcp-abap-adt/interfaces`, released before the connector consumes it — the standing rule, no local bridge.
-
-## The hard part, named
-
-`JwtAbapConnection` is 483 lines and **most of it is not authentication.** `renewalInFlight`, the `AsyncLocalStorage` operation scopes, `tokenGeneration` against `recoveredGeneration`, `ensureRecovered`, and the calls to `discardSession()` and `recoverSession()` are about what happens to *the session* when the credential is renewed mid-flight. That is connection business and stays in the base.
-
-The split to make:
-
-- **credential**: "get me a valid token" → the provider, behind `IAbapCredential`;
-- **connection**: "the credential changed, so the session it built is gone — discard, re-establish, let the request retry once" → the base, unchanged in behaviour.
-
-If this line is drawn wrongly the 4.0.0 work is undone, and that work exists because the failures it fixed were subtle: two layered single-flight promises, identity-checked clears, an epoch checked before a retry. **The spec's success condition is that every test from 4.0.0 passes untouched.**
-
-## Migration
-
-The five current classes stay, deprecated, as thin wrappers: `new JwtAbapConnection(config, logger, sessionId, refresher)` builds `AdtCloudConnector` with a token credential. Nothing published breaks, and `createAbapConnection()` keeps working from `SapConfig` alone.
-
-New code takes a connector and hands it a credential.
-
-## What this does not do
-
-- **No auto-detection**, in any form — see above.
-- **No change to the two session strategies.** They were measured against a live trial and an on-prem system and are not the subject here.
-- **No new auth mechanism.** Only a place for the ones that exist to be passed in.
-- **No dependency on the auth packages.** The connector keeps speaking contracts; consumers supply implementations, as with `IAbapConnection` today.
-
-## Open, to settle in review
-
-1. **`prepare()` and Kerberos.** SPNEGO deliberately does not prepare early: minting the token sooner changes when the exchange happens, and that path is not production-tested. Does Kerberos keep opting out, or does the contract grow a way to say "prepare late"?
-2. **What `createAbapConnection(config)` does when the config does not say which system it is.** Defaulting to on-prem keeps every existing consumer working and never guesses; refusing is more honest and breaks them. Deprecation-shaped default seems right, but it is a decision.
-3. **Whether `AdtOnPremConnector` should refuse the ADT session resource explicitly** — it exists there and answers, so a future edit could quietly start using it.
-
-## How it gets verified
-
-- Cloud: from this machine, against the BTP trial — connect, hold a session across stateful requests, disconnect. Already the way the current mechanism was measured.
-- On-prem: not reachable from here. Reviewed and run on the machine that reaches a system, as PR #34 was: strategy `icf`, `lock → PUT` chains, session present, and **no request to the session resource**.
-- Both wrong rows from the table above become tests: a cloud connector with a basic credential must use the ADT session; an on-prem connector with a token credential must not.