@foggy-projects/deepseek-harness-plugin 0.4.0-beta.14 → 0.4.0-beta.15

package/README.md

@@ -14,7 +14,7 @@ modify `PATH`, or register Python globally. Advanced users may explicitly set
 ## Local beta installation
 
 ```powershell
-dsh plugin --profile web add --workspace-root ./foggy-projects-deepseek-harness-plugin-0.4.0-beta.14.tgz
+dsh plugin --profile web add --workspace-root ./foggy-projects-deepseek-harness-plugin-0.4.0-beta.15.tgz
 ```
 
 Restart `dsh web`, use the browser it opens (or the complete printed URL,
@@ -30,9 +30,13 @@ dsh plugin --profile web add --workspace-root @foggy-projects/deepseek-harness-p
 For development, `FOGGY_ASSET_CACHE_DIRS` can contain platform-delimited verified
 asset-cache directories. It is not required for a normal install.
 
-Database credentials remain outside the ordinary DSH settings document. The
-bundled onboarding Skill drives datasource discovery, semantic drafting,
-checkpointed publication, and bounded read-only query verification.
+The bundled onboarding Skill is intentionally development-first. Users may
+provide a local datasource password in the conversation, a user-managed
+connection file, an Agent environment variable, or a compatible Runtime
+Console. Direct passwords are submitted to the already-running Runtime without
+being copied into onboarding state or evidence. The Skill then drives schema
+discovery, semantic drafting, local Bundle registration, and bounded query
+verification without restarting Runtime.
 
 ## Native Skill and workspace contract
 
@@ -42,14 +46,12 @@ are available in every DSH workspace without copying or symlinking `.agents`.
 The current session `cwd` remains the workspace boundary for semantic drafts and
 evidence.
 
-Opaque CLI profiles default to the private persistent
-`<dataRoot>/cli-profiles` directory. Composite onboarding commands are
+Opaque CLI profiles remain available for users who prefer them and default to
+the private persistent `<dataRoot>/cli-profiles` directory, but they are not a
+prerequisite for ordinary development. Composite onboarding commands are
 idempotent: unchanged completed phases are resumed rather than re-adding a
-datasource or re-registering a published bundle. Settings detects legacy
-temporary profiles and offers an explicit, validated migration into the
-persistent store. A completed profile can also be bound non-destructively to an
-additional DSH workspace when its reviewed connection contract and published
-semantic digest are unchanged.
+datasource or re-registering a local Bundle. Settings detects legacy temporary
+profiles and offers an explicit, validated migration into the persistent store.
 
 Private Python, CLI, Launcher, the analysis Skill, install state, and Runtime
 state live in the user-level Foggy component directories. The managed CLI is intentionally isolated
@@ -73,9 +75,11 @@ same wildcard binding used by the Java server, so a conflicting application or W
 port proxy produces an immediate, high-visibility error instead of a readiness timeout.
 The CLI and Skills resolve the resulting stable Runtime URL from managed state.
 
-This beta remains a local dev/test integration. The bundled Runtime reports
-`securityMode=none-dev-test-only` and must not be exposed to a network or used as
-a production service.
+This beta remains a local dev/test integration. It does not automatically extend
+local credentials or approvals into a formal environment. Production model
+publication should use a separate manual or dedicated deployment workflow with
+an explicit target, model Git commit/tag, credentials, verification, and
+rollback plan.
 
 See [`docs/PUBLIC-BETA-READINESS.md`](./docs/PUBLIC-BETA-READINESS.md) for the
 tested public Beta scope, release gates, and stable-release blockers.

package/docs/PUBLIC-BETA-READINESS.md

@@ -1,10 +1,10 @@
-# Public beta readiness: 0.4.0-beta.14
+# Public beta readiness: 0.4.0-beta.15
 
 Assessment date: 2026-09-04
 
 ## Verdict
 
-`0.4.0-beta.14` is suitable for a scoped public beta on Windows 10/11 x64 and
+`0.4.0-beta.15` is suitable for a scoped public beta on Windows 10/11 x64 and
 Linux/WSL2 x64. It is not a general-availability release.
 
 The plugin package stays small and downloads large components only during
@@ -26,8 +26,22 @@ system PATH, registry, or a user's existing Python installation.
 - WSL2 reported the existing managed Python, CLI, Launcher, and analysis Skill
   as ready; an isolated Windows profile correctly reported its fresh component
   state and rejected the host's Java 12 as below the Java 17 prerequisite.
+- Onboarding is development-first: a direct password or Agent environment
+  variable is submitted to the public datasource API of an already-running
+  Runtime. The password is excluded from onboarding state and evidence, and
+  datasource setup does not trigger Runtime restart. Opaque profiles remain an
+  optional advanced path.
+- A real Launcher 0.1.18 smoke on Java 17 accepted a synthetic inline-password
+  datasource through the public Runtime API while retaining the same Java PID.
+  The isolated registry confirmed the documented local-development plaintext
+  persistence boundary; the test datasource was then removed and the temporary
+  Runtime stopped.
+- A full isolated `onboard-datasource-run` then created, tested, bound, and
+  inspected a SQLite datasource containing one table. Runtime retained the same
+  PID, while the persisted onboarding state and command evidence contained no
+  copy of the synthetic password.
 - The UI reported Python 3.12.13 as `Foggy private`, and CLI 0.1.23, Launcher
-  0.1.18, analysis Skill 0.1.17, and onboarding Skill 0.4.0-beta.14 as installed.
+  0.1.18, analysis Skill 0.1.17, and onboarding Skill 0.4.0-beta.15 as installed.
 - Runtime startup now reports the current phase, elapsed/timeout seconds, and a
   bounded progress value. A real Windows launch with Temurin 17 reached readiness
   and passed capabilities in 18.9 seconds. A controlled post-launch Java exit was
@@ -47,8 +61,10 @@ system PATH, registry, or a user's existing Python installation.
   downloaded artifacts are not trusted until the complete SHA256 matches.
 - Windows progress writes tolerate transient sharing violations without losing
   the previous valid progress document or leaving temporary files behind.
-- Automated regression passed on Windows and Linux/WSL2: 20 Node tests and 17
-  Python tests on each platform, plus shell and PowerShell syntax checks.
+- Current automated regression passes 20 Node tests and 20 Python tests. The
+  new datasource tests cover secret-free persisted state, direct Runtime API
+  submission, CLI bypass for inline development credentials, and output
+  redaction.
 
 ## Beta boundaries
 
@@ -63,6 +79,10 @@ system PATH, registry, or a user's existing Python installation.
 - Runtime production authentication is outside this beta's default local
   onboarding mode. The UI and doctor continue to report `productionReady=false`
   for the development-only no-auth mode.
+- Direct development passwords are stored by the current Runtime in its private
+  local datasource registry. Production publication is a separate manual or
+  future dedicated deployment workflow and should use the target environment's
+  credential controls.
 
 ## Release gate after publication
 

package/docs/WINDOWS-BETA-ACCEPTANCE.md

@@ -1,7 +1,7 @@
 # Native Windows Beta acceptance
 
 This runbook validates DeepSeek Harness `0.1.2-rc.1` with Foggy plugin
-`0.4.0-beta.14` on a clean 64-bit Windows 10 or Windows 11 machine. Use a local
+`0.4.0-beta.15` on a clean 64-bit Windows 10 or Windows 11 machine. Use a local
 directory that is not synchronized by OneDrive.
 
 ## Prerequisites
@@ -54,7 +54,7 @@ Expected component state:
 - CLI 0.1.23;
 - Launcher 0.1.18;
 - analysis Skill 0.1.17;
-- onboarding Skill 0.4.0-beta.14;
+- onboarding Skill 0.4.0-beta.15;
 - Java 17+ available;
 - native DSH Skill registration available.
 
@@ -74,21 +74,24 @@ starting again must clear the applicable conflict state.
 
 ## Database and semantic-layer acceptance
 
-Keep database credentials out of this public repository. Create a private CLI
-profile outside the DSH conversation, pass only its opaque profile ID and
-revision to the onboarding workflow, and use a test-only database account with
-read-only permissions.
+Use a development or test database. For this local acceptance run, connection
+details and a password may be supplied directly in the prompt or in a local
+connection JSON file. The onboarding wrapper must configure the datasource
+online without stopping or restarting an already-running Runtime. It must not
+copy the password into onboarding state, evidence, TM/QM files, or Git.
 
 Use a natural prompt such as:
 
 ```text
-请帮我用 Foggy 分析这个测试数据库。我已经按验收手册创建了私有连接
-profile。请先确认连接和表结构，再围绕订单数据创建一个简单的语义层，
-包含订单数量、状态和开单时间，最后执行一个不超过 20 行的只读查询。
-不要修改数据库，也不要在对话或验收文件中输出密码。
+请帮我用 Foggy 分析这个测试数据库：地址、数据库名、账号和密码分别是
+<连接信息>。直接创建开发数据源并绑定一个合适的 namespace，不要重启
+Runtime。读取表结构后，在当前工作目录创建订单语义模型，包含订单数量、
+状态和开单时间，调试到模型通过，并执行一个不超过 20 行的只读查询。
 ```
 
-Pass only when Runtime readiness and capabilities succeed, datasource metadata
-can be discovered, TM/QM models validate and publish, the bounded read-only
-query succeeds, diagnostics contain no credentials, and stopping Runtime frees
-the configured port (default `18166`).
+Pass only when Runtime readiness and capabilities succeed, datasource setup
+does not restart Runtime, metadata can be discovered, TM/QM models validate and
+become effective in the local Runtime, the bounded read-only query succeeds,
+diagnostics contain no credentials, and stopping Runtime frees the configured
+port (default `18166`). Recommend Git management for the completed model files;
+do not treat this acceptance run as production publication.

package/experience/linux/prepare.sh

@@ -3,7 +3,7 @@ set -euo pipefail
 
 DSH_VERSION="0.1.2-rc.1"
 PNPM_VERSION="11.7.0"
-PLUGIN_VERSION="0.4.0-beta.14"
+PLUGIN_VERSION="0.4.0-beta.15"
 PLUGIN_REF="v${PLUGIN_VERSION}"
 PLUGIN_REPOSITORY="https://github.com/foggy-projects/foggy-deepseek-harness-plugin.git"
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@foggy-projects/deepseek-harness-plugin",
-  "version": "0.4.0-beta.14",
+  "version": "0.4.0-beta.15",
   "description": "Foggy Java data analysis engine integration for DeepSeek Harness",
   "type": "module",
   "main": "./lib/index.js",

package/skills/foggy-deepseek-onboarding/SKILL.md

@@ -1,137 +1,116 @@
 ---
 name: foggy-deepseek-onboarding
-description: Install and operate a pinned Foggy CLI-first dev/test environment from DeepSeek Harness, including opaque datasource profiles, resumable verification, and schema discovery before semantic authoring. Use for initial Foggy setup or local Runtime onboarding; do not use for production deployment or MCP configuration.
+description: Set up and use Foggy Runtime for data-source exploration and semantic-model development inside DeepSeek Harness. Use for local experience, datasource onboarding, TM/QM authoring, validation, and development publication; route production deployment or updates to a separate release workflow.
 ---
 
 # Foggy DeepSeek onboarding
 
-Set up Foggy through shell and `foggy-runtime` CLI. Do not configure Foggy MCP for this local workflow.
-
-## Native registry and installed-state gate
-
-This Skill is registered by the Foggy plugin through DeepSeek Harness's native Skill registry. Its
-resource base is the authoritative location for these scripts and references; do not search for or
-copy this Skill into the current workspace.
-
-- Resolve the global install state from the platform default component directory: on Linux use
-  `${XDG_DATA_HOME:-$HOME/.local/share}/foggy/deepseek-harness/install-state.json`; on Windows use
-  `%LOCALAPPDATA%\Foggy\DeepSeekHarness\install-state.json`.
-- Confirm the installation with this Skill's `doctor` wrapper and pass the current DSH session
-  workspace as `--project-root`. The absence of `foggy-runtime` from `PATH` is not evidence that the
-  managed CLI is missing; the plugin intentionally installs it in an isolated environment and records
-  its absolute command in the global install state.
-- The plugin downloads and verifies a pinned private Python runtime before running this Skill. Do not
-  search for, install, or repair a system Python. Wrappers resolve the interpreter recorded in the
-  global install state. If private Python is missing, use the plugin's Python repair action. Only use
-  `FOGGY_PYTHON` or `FOGGY_ONBOARDING_PYTHON` when the user explicitly supplied an advanced override.
-- Do not independently download or reinstall the CLI. If the global install state, managed marker, or
-  analysis Skill is missing or invalid, ask the user to open the Foggy plugin settings and use
-  the matching component repair action. Repair restores managed components and invalidates the
-  native DSH Skill catalog. Reinstall or upgrade the plugin itself to restore this bundled Skill.
-- Treat the current DSH session workspace as the authoritative `projectRoot` for the whole onboarding
-  run. Do not redirect semantic drafts or contracts to a different repository merely because another
-  Skill or example was found there. Place non-secret contracts below
-  `<projectRoot>/.foggy/onboarding-contracts/<profile>/`, drafts below
-  `<projectRoot>/.foggy/onboarding-drafts/<profile>/`, and published files below the approved
-  project-relative `modelsDir`.
-
-## Mandatory orchestration boundary
-
-For every new-database onboarding session, this Skill is the orchestration authority until
-`onboard-status` reports `next.status=completed`:
-
-- Invoke datasource, schema, semantic, bundle, and query operations only through this Skill's
-  `scripts/onboard.ps1` or `scripts/onboard.sh`. Do not call `foggy-runtime` directly for those
-  operations, even if another loaded Skill documents equivalent CLI commands.
-- Use `foggy-ai-analysis` only to author TM/QM draft content. Its general direct-CLI workflow does not
-  supersede this Skill's state machine, approval gates, names, paths, query limit, or evidence rules.
-- Use the exact profile, datasource, namespace, bundle, model names, paths, fields, and query limit
-  supplied or confirmed by the user. Do not replace them with examples or inferred alternatives.
-- Do not use raw SQL to sample business rows during onboarding. `schema-discover` is the metadata gate;
-  any later SQL probe requires separate explicit approval and must be bounded and read-only.
-- Never use `--replace`, `--replace-bundle`, `--prune`, `--watch`, or `--execute` unless that exact
-  mutation was explicitly approved. Approval for adding a new resource is not approval to replace one.
-- Save each wrapper result as the single JSON object returned on stdout when the user requests evidence.
-  Do not claim completion when required evidence is missing or the persisted status is incomplete.
-- Never read query-execution evidence back into the conversation. Report only validation state,
-  execution state, row count, and evidence path; do not report row values or generated SQL containing
-  business literals.
-- Prefer one composite command per approval boundary. Do not inspect this Skill's Python implementation
-  or the CLI package source during a normal run; use the documented command contract and inspect code
-  only after a structured wrapper error requires troubleshooting.
-
-## Boundaries
-
-- Treat the bundled Launcher as local dev/test only. Its expected security mode is
-  `none-dev-test-only`; never expose it to a network.
-- Do not print, persist, or request secrets in chat. Use named environment variables or a private env
-  file outside the Skill and evidence directories.
-- Do not modify Foggy engine or CLI source. If setup cannot continue without such a change, stop and
-  ask the user for explicit authorization.
-- Before downloads, installs, replacement, Runtime start/stop, or removal, state the concrete action
-  and obtain any authorization required by the host.
-
-## Workflow
-
-1. Run `scripts/doctor.ps1 --project-root <current-session-workspace>` on Windows or
-   `bash scripts/doctor.sh --project-root <current-session-workspace>` on Linux.
-2. If private Python, the pinned CLI, Launcher, or global managed analysis Skill is missing, use the
-   Foggy plugin's matching Repair action. First-time Python bootstrap requires the plugin UI unless
-   the user explicitly supplies `FOGGY_ONBOARDING_PYTHON`. Use a matching install script only after
-   private Python exists and the plugin UI is unavailable; use `--dry-run` first when paths or
-   permissions are uncertain.
-3. Run `runtime-start` and require successful `wait-ready` plus `capabilities`. Record engine,
-   Runtime API version, schema version, security mode, URL, namespace, PID, and evidence path. If the
-   recorded Runtime is already running, `runtime-start` verifies and reuses it instead of starting a
-   second process.
-4. Load `foggy-ai-analysis` from the native DSH Skill registry. Do not require a workspace copy.
-5. For a new business database, read [references/onboarding-workflow.md](references/onboarding-workflow.md)
-   and prefer its two composite `onboard-datasource-run` / `onboard-semantic-run` commands. Require the
-   trusted operator to create the private CLI profile outside Harness. Unless the operator explicitly
-   overrides it, use the persistent profile store reported by the wrapper under the Foggy data root
-   (`<dataRoot>/cli-profiles`), never `/tmp`. Accept only the opaque profile
-   ID, exact revision, datasource name/type, and namespace; never request JDBC URL, username,
-   password, or password environment-variable name in Harness.
-   If plugin settings report a legacy temporary profile, use the explicit migration action before
-   onboarding. It moves only validated connection metadata and environment-variable references; it
-   never copies a password value and leaves a recoverable private backup below the Foggy data root.
-6. After schema discovery, use `foggy-ai-analysis` only to author TM/QM files in the standard project-local
-   draft directory. Register, validate, publish, and verify them through this Skill's wrapper using the deterministic commands in
-   [references/onboarding-workflow.md](references/onboarding-workflow.md). Do not publish, prune, replace
-   a bundle, or execute a business-data query without the matching explicit flag and user approval.
-7. Stop only the Runtime PID recorded by this package. Preserve Runtime data unless the user explicitly
-   requests purge.
-
-## Command contract
-
-All package scripts return one JSON object on stdout. Treat `success=false` or a nonzero exit code as a
-failure. Do not infer readiness from a fixed sleep; require CLI `wait-ready` and `capabilities`.
-
-Use this analysis order after setup:
+Use this Skill for the normal DeepSeek Harness experience: connect a development datasource, inspect
+it, create TM/QM files in the current workspace, and iterate until queries pass. Use the managed
+`foggy-runtime` CLI and this Skill's wrappers; do not configure Foggy MCP for this local workflow.
+
+## Product boundary
+
+- Treat the plugin and bundled Launcher as local experience and development tooling.
+- Datasources, namespace bindings, model Bundles, refreshes, and query checks are online Runtime
+  operations. They do not require a Runtime restart.
+- Start Runtime only when it is absent. Reuse a healthy running Runtime. Restart only when the user
+  asks, a Launcher/JAR upgrade requires it, Runtime is unhealthy, or an actual startup setting such as
+  port, JVM options, Runtime authentication, or an opt-in module changes.
+- Do not turn production publication into a continuation of local onboarding. When the user wants to
+  deploy or update a formal environment, recommend a manual release or a dedicated production
+  deployment workflow with separately supplied target access, credentials, version, verification, and
+  rollback information.
+- Do not modify Foggy engine or CLI source. If progress genuinely requires either change, stop and ask
+  for explicit authorization.
+
+## Managed installation
+
+This Skill is registered through DeepSeek Harness's native Skill registry. Its scripts and references
+are authoritative; do not copy the Skill into the current workspace.
+
+- Linux install state: `${XDG_DATA_HOME:-$HOME/.local/share}/foggy/deepseek-harness/install-state.json`.
+- Windows install state: `%LOCALAPPDATA%\Foggy\DeepSeekHarness\install-state.json`.
+- Run this Skill's `doctor` wrapper with the current DSH workspace as `--project-root`. The managed CLI
+  is intentionally isolated, so absence from `PATH` does not mean it is missing.
+- Use plugin settings to initialize or repair private Python, CLI, Launcher, or the managed analysis
+  Skill. Do not independently reinstall them during a normal analysis session.
+- Treat the current DSH workspace as `projectRoot`. Keep model drafts and final model files there rather
+  than redirecting them to an example repository.
+
+## Development workflow
+
+1. Run `doctor`. Start Runtime only if it is not already healthy; require `wait-ready` and
+   `capabilities` after a new start.
+2. Accept datasource connection details from the user's message, a user-supplied local JSON file, an
+   environment variable, or Runtime Console. Direct `password` is supported for local development.
+   The wrapper submits it to the public Runtime API without copying it into onboarding state or
+   evidence. Do not echo it in the response.
+3. Create or select the namespace, add/test the datasource online, and bind it to the namespace. Do
+   not stop or restart Runtime to make a password available. A running Runtime can accept a direct
+   development password through its datasource API.
+4. Inspect tables, columns, keys, and relationships. Small, bounded, read-only SQL samples are allowed
+   when they help infer captions, enums, units, or date semantics. Do not run mutations unless the user
+   explicitly requests them.
+5. Load `foggy-ai-analysis` from the native registry only for TM/QM authoring and query tuning; its
+   generic installation, datasource-secret, and production-deployment guidance does not override this
+   development workflow. Default to a project-local `models/` directory unless the user specifies
+   another directory.
+6. Iterate through model validation, Bundle registration/update, model refresh/describe, query
+   validation, and bounded query execution. Development publication means making the local model
+   directory effective in this local Runtime; it is not a production release.
+7. When the model works, recommend committing the model directory to the user's own Git repository.
+   Do not initialize a repository, commit, push, or create a remote unless the user requests it.
+
+Read [references/onboarding-workflow.md](references/onboarding-workflow.md) for the wrapper commands and
+credential shapes. Use `foggy-ai-analysis` references for detailed TM/QM modeling and query tuning.
+
+## Credential choices for local development
+
+Choose the simplest source the user provides:
+
+- `password` in a connection file: simplest for an experience session; the source file remains under
+  the user's control and should normally stay outside Git.
+- `passwordEnv`: the wrapper reads the variable from the Agent process and submits the value online;
+  Runtime does not need to inherit it at startup.
+- Opaque profile: optional for users who already have one; never require it for ordinary onboarding.
+- Runtime Console: when a Launcher exposing Runtime Console is installed, the user may enter the
+  connection there using the management token shown by the host/plugin.
+
+Keep only a minimal development safety baseline: do not echo passwords, put them in TM/QM files,
+include them in evidence/diagnostics, or commit them to Git. Do not impose production IAM, audit,
+approval, secret-store, or network-governance requirements on this local flow.
+
+## Command behavior
+
+All scripts emit one JSON object. Treat `success=false` or a nonzero exit code as failure. Prefer the
+two resumable composite commands for a complete requested experience:
 
 ```text
-datasource test -> bind -> diagnostics
-tables list -> inspect -> optional bounded read-only SQL
-models validate -> bundles add/update -> models refresh -> models describe
-query validate -> query execute -> interpretation
+onboard-datasource-run --project-root <workspace> --connection-file <json> \
+  --approve-configure --approve-bind --include-indexes
+
+onboard-semantic-run --project-root <workspace> --semantic-plan <json> \
+  --query-payload <json> --approve-validate --approve-publish --approve-execute
+```
+
+When the user has already asked to connect, build, and test a new local model, those flags implement
+that request and do not require separate question-by-question confirmation. Replacement, pruning, broad
+queries, destructive SQL, Git push, and production deployment still require their own clear scope.
+
+The normal analysis order is:
+
+```text
+datasource add/test -> namespace bind -> table/schema inspection
+TM/QM authoring -> models validate -> bundle add/update -> refresh/describe
+query validate -> bounded query execute -> tune -> optional Git handoff
 ```
 
-In DeepSeek Harness, do not expand the composite onboarding commands back into these individual CLI
-operations. This order documents what the wrapper enforces internally and becomes a direct CLI workflow
-only after onboarding is complete.
-
-Composite commands are checkpointed and idempotent: a retry skips completed datasource, validation,
-publication, and verification phases when the approved contract and draft digest are unchanged. Fix a
-query payload in place and rerun the same semantic composite command; do not remove a successfully
-published bundle merely to recover from a later query-validation failure.
-
-An already-completed profile may be reused from another DSH workspace when the approved connection
-contract is byte-for-byte equivalent. Run the datasource composite in the new workspace first; it adds
-that workspace as a non-destructive binding and reuses datasource/schema checkpoints. Then pass the
-current workspace explicitly as `--project-root` to the semantic composite. A secondary workspace may
-reuse an identical published semantic digest and run its own bounded verification query, but it cannot
-replace the published semantic layer; changes must be published from the original workspace or a new
-profile.
-
-Keep user business data separate from the sales-drop SQLite demo. Prefer a read-only database account,
-opaque CLI profile references, and bounded query limits.
+Stop only the PID recorded by this package and preserve the Runtime work directory unless the user
+explicitly requests removal.
+
+## Result
+
+Report the Runtime URL, namespace, datasource name, model directory, Bundle and QueryModel names,
+validation/query status, and useful evidence paths. Never include the password or business row values
+unless the user specifically asks for those values.

package/skills/foggy-deepseek-onboarding/assets/connection.schema.json

@@ -12,6 +12,7 @@
     "type": {"enum": ["sqlite", "mysql", "postgres", "postgresql"]},
     "jdbcUrl": {"type": "string", "minLength": 1},
     "username": {"type": "string"},
+    "password": {"type": "string", "description": "Optional local development password. It is submitted once and is not copied into onboarding state or evidence."},
     "passwordEnv": {"type": "string", "pattern": "^[A-Za-z_][A-Za-z0-9_]*$"},
     "opaqueProfileId": {"type": "string", "pattern": "^fop_[a-f0-9]{32}$"},
     "opaqueRevision": {"type": "string", "pattern": "^sha256:[a-f0-9]{64}$"},
@@ -27,6 +28,7 @@
       "not": {"anyOf": [
         {"required": ["jdbcUrl"]},
         {"required": ["username"]},
+        {"required": ["password"]},
         {"required": ["passwordEnv"]}
       ]}
     },
@@ -38,13 +40,9 @@
       ]}
     }
   ],
-  "allOf": [
-    {
-      "if": {
-        "required": ["jdbcUrl"],
-        "properties": {"type": {"not": {"const": "sqlite"}}}
-      },
-      "then": {"required": ["passwordEnv"]}
+  "allOf": [{
+    "not": {
+      "required": ["password", "passwordEnv"]
     }
-  ]
+  }]
 }

package/skills/foggy-deepseek-onboarding/assets/datasource.example.json

@@ -3,8 +3,9 @@
   "profile": "business",
   "name": "business-db",
   "type": "mysql",
-  "opaqueProfileId": "fop_0123456789abcdef0123456789abcdef",
-  "opaqueRevision": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
+  "jdbcUrl": "jdbc:mysql://127.0.0.1:3306/business",
+  "username": "business_dev",
+  "password": "replace-for-local-development",
   "namespace": "business",
   "schemas": ["public"],
   "modelsDir": "models",

package/skills/foggy-deepseek-onboarding/assets/env.example

@@ -1,5 +1,5 @@
-# Copy only the variables you need into a private, gitignored env file.
-# Never put provider keys or database passwords in DSH settings, Skill files, or evidence.
+# Optional development configuration. Direct passwords in a user-supplied connection file are also
+# supported; the onboarding wrapper does not copy them into state or evidence.
 
 FOGGY_RUNTIME_API_URL=http://127.0.0.1:18166
 FOGGY_NAMESPACE=default
@@ -10,5 +10,5 @@ FOGGY_NAMESPACE=default
 # Optional data-plane authorization value.
 # FOGGY_RUNTIME_AUTHORIZATION=
 
-# Example datasource password reference. Use a datasource-specific variable name.
+# Optional alternative to a direct development password.
 # FOGGY_DATASOURCE_PASSWORD=

package/skills/foggy-deepseek-onboarding/assets/onboarding-state.schema.json

@@ -34,7 +34,29 @@
       }
     },
     "runtime": {"type": "object"},
-    "connection": {"$ref": "connection.schema.json"},
+    "connection": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["schemaVersion", "connectionMode", "name", "type", "namespace"],
+      "properties": {
+        "schemaVersion": {"const": "foggy-deepseek-connection/v1"},
+        "connectionMode": {"enum": ["legacy-inline", "opaque-profile"]},
+        "credentialMode": {"enum": ["inline-development", "agent-environment", "opaque-profile", "none"]},
+        "name": {"type": "string"},
+        "type": {"type": "string"},
+        "jdbcUrl": {"type": ["string", "null"]},
+        "username": {"type": ["string", "null"]},
+        "passwordEnv": {"type": ["string", "null"]},
+        "opaqueProfileId": {"type": "string"},
+        "opaqueRevision": {"type": "string"},
+        "namespace": {"type": "string"},
+        "schemas": {"type": "array", "items": {"type": "string"}},
+        "modelsDir": {"type": "string"},
+        "readOnlyRecommended": {"type": "boolean"},
+        "profile": {"type": "string"},
+        "evidenceDir": {"type": "string"}
+      }
+    },
     "semantic": {"type": "object"},
     "steps": {"type": "object"},
     "artifacts": {"type": "object"}

package/skills/foggy-deepseek-onboarding/assets/versions.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": "foggy-deepseek-onboarding-versions/v1",
-  "packageVersion": "0.4.0-beta.14",
+  "packageVersion": "0.4.0-beta.15",
   "validatedAt": "2026-09-04",
   "components": {
     "deepseekHarness": {

package/skills/foggy-deepseek-onboarding/references/onboarding-workflow.md

@@ -1,156 +1,146 @@
-# Resumable database onboarding
-
-Use the thin `scripts/onboard.ps1` or `scripts/onboard.sh` entrypoint. Every command emits one JSON
-object. Preserve the returned `next` instruction and use `onboard-status` or `onboard-resume` after an
-interruption.
-
-The wrapper is mandatory for the entire sequence below. Until `onboard-status` returns
-`next.status=completed`, do not substitute direct `foggy-runtime datasources`, `tables`, `sql`, `models`,
-`bundles`, or `query` calls. A second Skill may help write draft TM/QM files, but must not take over
-orchestration. Do not inspect sample rows to author the semantic layer; use schema metadata plus the
-business definitions confirmed by the user.
+# Development datasource and semantic-model workflow
+
+Use this workflow after the Foggy plugin is initialized. It is designed for local experience and
+model development in DeepSeek Harness, not for production deployment.
+
+## Connection input
+
+The simplest local connection contract may contain a direct password:
+
+```json
+{
+  "schemaVersion": "foggy-deepseek-connection/v1",
+  "profile": "business",
+  "name": "business-db",
+  "type": "mysql",
+  "jdbcUrl": "jdbc:mysql://127.0.0.1:3306/business",
+  "username": "business_dev",
+  "password": "local-development-password",
+  "namespace": "business",
+  "modelsDir": "models",
+  "evidenceDir": ".foggy/onboarding-command-evidence/business"
+}
+```
 
-## Conversation contract
+The wrapper uses the direct password only while submitting the datasource to the public Runtime API.
+It does not copy it into onboarding state, command evidence, TM/QM files, or conversational output.
+The source connection file is user-managed; do not commit it. The local Runtime currently stores a
+direct password in its private datasource registry, so use `passwordRef`-style production credential
+management when moving beyond local development.
+
+An environment variable is an optional alternative:
+
+```json
+{
+  "schemaVersion": "foggy-deepseek-connection/v1",
+  "profile": "business",
+  "name": "business-db",
+  "type": "mysql",
+  "jdbcUrl": "jdbc:mysql://127.0.0.1:3306/business",
+  "username": "business_dev",
+  "passwordEnv": "FOGGY_BUSINESS_DB_PASSWORD",
+  "namespace": "business",
+  "modelsDir": "models"
+}
+```
 
-Collect these non-secret values before creating a plan:
+Here `passwordEnv` is read by the onboarding wrapper and submitted online to the already-running
+Runtime. Do not restart Runtime merely to make the variable part of the Java process environment.
+Opaque CLI profiles remain supported for users who already prefer them, but are not required for a
+normal DSH experience.
 
-1. an opaque Foggy profile ID and its exact reviewed revision;
-2. datasource name, database type, and namespace from the CLI's public profile summary;
-3. optional schemas, the project-relative semantic model directory, and a project-relative evidence directory.
+## Normal sequence
 
-Create the private profile in a trusted operator session outside DeepSeek Harness. Do not ask the user
-to paste a password and do not put a JDBC URL, username, password environment-variable name, or password in the JSON plan, command
-line, logs, or evidence. For non-SQLite databases, ask the user to set the named environment variable
-before Runtime starts so the Java process inherits it. Recommend a read-only database account.
+Run the platform-specific wrapper from this Skill directory. `onboard-datasource-run` performs the
+online datasource setup, namespace binding, and schema discovery against the healthy Runtime:
 
-Use the current DSH session workspace as `projectRoot`. Store approved non-secret contracts at
-`.foggy/onboarding-contracts/<profile>/`, semantic drafts at `.foggy/onboarding-drafts/<profile>/`, and
-command evidence at `.foggy/onboarding-command-evidence/<profile>/`. Do not split these files across the
-session workspace and a separate example repository. The wrapper rejects a query payload outside the
-recorded project root before any semantic validation or publication mutation occurs.
+```text
+onboard-datasource-run --project-root <current-workspace> \
+  --connection-file <connection-json> \
+  --approve-configure --approve-bind --include-indexes
+```
 
-The wrapper defaults `FOGGY_RUNTIME_PROFILE_STORE` to the private persistent directory
-`<dataRoot>/cli-profiles`. An explicit operator-provided value still wins. Do not use `/tmp` for a profile
-that must survive a WSL or Harness restart.
+If the user already requested the complete connection experience, include both approval flags in the
+first call. They refer only to adding the named development datasource and binding the requested
+namespace. Do not add `--replace` unless replacement was explicitly requested.
 
-If plugin settings detect profiles in the legacy temporary store, use **Move to persistent store**.
-Migration validates the opaque profile schema, rejects embedded passwords and conflicts, writes the
-destination with private permissions, verifies it, and moves the legacy JSON to a recoverable private
-backup below the Foggy data root.
-Do not manually copy or edit opaque profile JSON.
+The command performs:
 
-Treat every user-supplied identifier and bound as immutable input: profile, datasource, namespace,
-models directory, bundle name, TM/QM name, query fields, and limit. Do not swap in demo names, add
-fields, raise the limit, or introduce replacement flags. If one of these inputs is missing, pause for
-that input rather than inventing it.
+```text
+datasource add -> datasource test -> namespace bind -> diagnostics
+tables list -> bounded schema inspection
+```
 
-For composite Harness execution, persist `profile` and `evidenceDir` inside both approved contract
-files. The wrapper derives them from the files and rejects conflicting command-line values. Present the
-normalized contracts to the user before accepting mutation approvals; do not combine contract drafting
-and approval into an unseen one-turn mutation.
+It does not stop or restart Runtime. Repeated calls reuse completed checkpoints when the public
+connection contract is unchanged. Inline password values are excluded from the comparison.
 
-Write the non-secret input using `assets/connection.schema.json`; `assets/datasource.example.json` is a
-template. Then execute the sequence below.
+After discovery, use `foggy-ai-analysis` to create TM/QM drafts from actual tables, columns, keys,
+small read-only samples when useful, and the user's business questions. Keep the files in the current
+workspace, normally:
 
-## Deterministic sequence
+```text
+models/
+  model/
+    <Name>.tm
+  query/
+    <Name>QueryModel.qm
+```
 
-For Harness-driven onboarding, use the two composite commands below. Each writes the numbered JSON
-evidence internally and refuses to cross an unapproved mutation gate:
+Then run the semantic composite:
 
 ```text
-onboard-datasource-run --project-root <current-session-workspace> \
-  --connection-file <approved-json> \
-  --approve-configure --approve-bind --include-indexes
-
-# After authoring the registered TM/QM draft from schema metadata:
-onboard-semantic-run --project-root <current-session-workspace> \
-  --semantic-plan <approved-json> --query-payload <approved-json> \
+onboard-semantic-run --project-root <current-workspace> \
+  --semantic-plan <semantic-json> \
+  --query-payload <bounded-query-json> \
   --approve-validate --approve-publish --approve-execute
 ```
 
-Include an approval flag only after the user approves that exact action. Without it, the composite
-command stops after the corresponding dry-run and returns `phaseStatus=awaiting-...-approval`.
+For an explicitly requested end-to-end local experience, these flags may be used together. The command
+validates the model files, copies them to the approved model directory when needed, registers or
+updates the local Runtime Bundle, refreshes/describes the declared QueryModels, validates the bounded
+query, and executes it. It never means production publication.
 
-Both composite commands are resumable. When the approved contract is unchanged, they skip completed
-checkpoints instead of re-adding an existing datasource, revalidating an already published draft, or
-registering the same bundle twice. If query validation fails after publication, correct the project-local
-payload and rerun `onboard-semantic-run`; it resumes at query verification and leaves the active bundle in
-place. A same-name datasource is accepted idempotently only when its public name and database type match
-the approved plan; otherwise replacement still requires explicit approval.
+Use `--watch` only when the user wants the local Runtime to follow model-file edits. Use `--prune` or
+bundle replacement only when the user clearly asks for those changes.
 
-When a completed profile already belongs to another workspace, the datasource composite may add the
-current workspace as a binding only if the approved connection contract is identical and the datasource,
-schema, and semantic publication checkpoints are complete. The semantic composite then accepts the same
-published draft digest from the bound workspace and performs a workspace-specific bounded verification
-query. It refuses semantic replacement from the secondary workspace.
+## Iteration and troubleshooting
 
-The granular commands below remain available for manual troubleshooting and resumption. Do not expand
-the composite commands into this list during a normal Harness turn.
+The granular commands remain available when a specific stage needs repair:
 
 ```text
 onboard-plan --connection-file <json> --profile <profile>
-datasource-configure --profile <profile>
-datasource-configure --profile <profile> --apply
-datasource-verify --profile <profile>
-datasource-verify --profile <profile> --bind
-schema-discover --profile <profile> --include-indexes
+datasource-configure --profile <profile> [--apply]
+datasource-verify --profile <profile> [--bind]
+schema-discover --profile <profile> [--include-indexes]
 semantic-draft --profile <profile> --semantic-plan <json>
-semantic-validate --profile <profile>
-semantic-validate --profile <profile> --apply
-semantic-publish --profile <profile>
-semantic-publish --profile <profile> --apply
-semantic-verify --profile <profile> --project-root <current-session-workspace> --query-payload <json>
-semantic-verify --profile <profile> --project-root <current-session-workspace> --query-payload <json> --execute
+semantic-validate --profile <profile> [--apply]
+semantic-publish --profile <profile> [--apply]
+semantic-verify --profile <profile> --query-payload <json> [--execute]
 onboard-status --profile <profile>
+onboard-resume --profile <profile>
 ```
 
-The first `datasource-configure` call is a dry run. Explain the concrete datasource mutation and get
-approval before adding `--apply`. `datasource-verify` tests connectivity without binding; explain the
-namespace binding mutation and get approval before adding `--bind`. Add `--replace` only when the user
-explicitly approves replacing an existing datasource definition.
-
-Schema discovery is metadata-only and inspects at most 25 tables by default. Use repeated `--schema` or
-`--table` arguments to narrow scope, `--list-only` for inventory only, and raise `--max-tables` only when
-the user needs broader inspection. The resulting evidence remains under the private Runtime data root.
-
-## Semantic authoring and publishing
-
-After `schemaDiscovered=completed`, review table names, columns, keys, and relationships with the user.
-Use `foggy-ai-analysis` for TM/QM authoring in a separate project-local draft directory. Do not invent
-business definitions, joins, units, enum meanings, or date semantics. Create a plan using
-`assets/semantic-plan.schema.json`; its declared query-model names must exist in the draft `.qm` files.
-
-`semantic-draft` records TM/QM hashes. Any later file change invalidates the recorded validation and must
-be registered and validated again. `semantic-validate` is a dry run until `--apply`; applying it may
-replace the Runtime validation catalog, so explain that mutation before approval.
-
-`semantic-publish` shows added, updated, unchanged, preserved, and optionally removed files. Applying it:
+A standalone `datasource-configure --apply` can resolve `passwordEnv` from its current Agent process.
+For a direct `password`, use the composite datasource command with the original connection file so the
+secret stays ephemeral to that invocation.
 
-1. backs up every overwritten or pruned project model file;
-2. copies the registered draft;
-3. validates the published directory;
-4. registers the bundle;
-5. refreshes only the declared query models.
+When a failure occurs, repair only the failed input and rerun the same composite command. Do not remove
+a successfully registered Bundle merely because later query validation failed. Keep SQL samples small,
+read-only, and relevant to semantic authoring.
 
-Use `--prune` only when the user approves removing target-only TM/QM files. Use `--replace-bundle` only
-when the user approves replacing an existing Runtime bundle, and `--watch` only when file watching is
-desired. A failure before refresh restores project files; a refresh failure is reported as a partial
-Runtime publication and must be diagnosed before retrying.
+## Git handoff
 
-For verification, build a project-local query payload only from `models describe` field names. The helper
-requires an integer `limit` from 1 through 100. The first `semantic-verify` call lists/describes models and
-validates the query; only `--execute` reads business data. Full results stay in evidence and the command
-returns only counts and paths.
+When validation and representative questions pass, recommend placing the model directory under the
+user's existing Git repository. Git is the source of truth for model history; Runtime Bundle
+registration only makes a selected local directory active. Do not create commits, remotes, tags, or
+pushes without the user's request.
 
-Before the first semantic mutation, the composite command checks that the query payload is inside
-`projectRoot`, has a bounded limit, and targets a query model declared in the approved semantic plan.
-After publication, `semantic-verify` always describes the live model before validation. If a field is
-rejected, update the payload from those described names and rerun the same composite command.
+## Production handoff
 
-Do not open, summarize, or quote `query-execute.json` or the Runtime's generated SQL after execution.
-The conversational result may contain only `queryValidated`, `queryExecuted`, `rowCount`, the model
-name, and the evidence path. A successful direct CLI command is not proof that onboarding completed;
-only the wrapper's persisted state with all steps `completed` is authoritative.
+Stop the local onboarding flow when the user asks to publish or update a formal environment. A separate
+manual or dedicated deployment workflow should collect the exact target, Launcher version, model Git
+commit/tag, namespace, production datasource procedure, access credentials, verification plan, and
+rollback point. It should then install/start Runtime if needed, prepare the target datasource, register
+the versioned model directory, refresh, and run a narrow smoke check.
 
-Do not bypass a failed step. If a command fails, report its structured error, fix only the relevant input
-or environment, and run `onboard-resume` to continue from the first incomplete step.
+Local onboarding credentials and approvals do not authorize production access or publication.

package/skills/foggy-deepseek-onboarding/scripts/onboarding.py

@@ -18,6 +18,7 @@ import subprocess
 import sys
 import tempfile
 import time
+import urllib.error
 import urllib.request
 import venv
 import zipfile
@@ -918,7 +919,7 @@ def validate_connection(payload: dict) -> dict:
     if payload.get("schemaVersion") != CONNECTION_SCHEMA:
         raise OnboardingError(f"connection schemaVersion must be {CONNECTION_SCHEMA}")
     allowed = {
-        "schemaVersion", "name", "type", "jdbcUrl", "username", "passwordEnv",
+        "schemaVersion", "name", "type", "jdbcUrl", "username", "password", "passwordEnv",
         "opaqueProfileId", "opaqueRevision",
         "profile", "namespace", "schemas", "modelsDir", "evidenceDir", "readOnlyRecommended",
     }
@@ -930,6 +931,7 @@ def validate_connection(payload: dict) -> dict:
     for name in required:
         if not isinstance(payload.get(name), str) or not payload[name].strip():
             raise OnboardingError(f"connection.{name} must be a non-empty string")
+    password = payload.get("password")
     password_env = payload.get("passwordEnv")
     jdbc_url = None
     if opaque:
@@ -937,15 +939,19 @@ def validate_connection(payload: dict) -> dict:
             raise OnboardingError("connection.opaqueProfileId must be an opaque Foggy profile ID")
         if not isinstance(payload.get("opaqueRevision"), str) or not OPAQUE_REVISION_PATTERN.fullmatch(payload["opaqueRevision"]):
             raise OnboardingError("connection.opaqueRevision must be a sha256 revision")
-        exposed = sorted(name for name in ("jdbcUrl", "username", "passwordEnv") if name in payload)
+        exposed = sorted(name for name in ("jdbcUrl", "username", "password", "passwordEnv") if name in payload)
         if exposed:
             raise OnboardingError(f"Opaque connection plans must not contain: {', '.join(exposed)}")
     else:
+        if password is not None and not isinstance(password, str):
+            raise OnboardingError("connection.password must be a string")
         if password_env is not None and (not isinstance(password_env, str) or not ENV_NAME_PATTERN.fullmatch(password_env)):
             raise OnboardingError("connection.passwordEnv must be an environment variable name")
+        if password is not None and password_env is not None:
+            raise OnboardingError("Provide either connection.password or connection.passwordEnv, not both")
         jdbc_url = payload["jdbcUrl"].strip()
         if re.search(r"(?i)(?:password|passwd|pwd)\s*=", jdbc_url) or re.search(r"//[^/@:]+:[^/@]+@", jdbc_url):
-            raise OnboardingError("Do not embed passwords in jdbcUrl; use passwordEnv")
+            raise OnboardingError("Do not embed passwords in jdbcUrl; use password or passwordEnv")
     schemas = payload.get("schemas", [])
     if not isinstance(schemas, list) or any(not isinstance(item, str) or not item.strip() for item in schemas):
         raise OnboardingError("connection.schemas must be an array of non-empty strings")
@@ -973,6 +979,7 @@ def validate_connection(payload: dict) -> dict:
     else:
         result["jdbcUrl"] = jdbc_url
         result["username"] = payload.get("username")
+        result["password"] = password
         result["passwordEnv"] = password_env
     if payload.get("profile") is not None:
         result["profile"] = safe_profile(payload["profile"])
@@ -980,11 +987,21 @@ def validate_connection(payload: dict) -> dict:
         result["evidenceDir"] = payload["evidenceDir"].strip()
     if result["type"] not in {"sqlite", "mysql", "postgres", "postgresql"}:
         raise OnboardingError("Initial onboarding supports sqlite, mysql, postgres, and postgresql")
-    if not opaque and result["type"] != "sqlite" and not result["passwordEnv"]:
-        raise OnboardingError("Non-SQLite connections require passwordEnv")
     return result
 
 
+def persisted_connection(connection: dict) -> dict:
+    """Return the resumable connection contract without an inline development password."""
+    persisted = {key: value for key, value in connection.items() if key != "password"}
+    persisted["credentialMode"] = (
+        "inline-development" if connection.get("password") is not None
+        else "agent-environment" if connection.get("passwordEnv")
+        else "opaque-profile" if connection.get("connectionMode") == "opaque-profile"
+        else "none"
+    )
+    return persisted
+
+
 def validate_semantic_plan(payload: dict) -> dict:
     if payload.get("schemaVersion") != SEMANTIC_PLAN_SCHEMA:
         raise OnboardingError(f"semantic plan schemaVersion must be {SEMANTIC_PLAN_SCHEMA}")
@@ -1780,6 +1797,64 @@ def cli_json(install_state: dict, runtime_state: dict, namespace: str, command:
     return payload
 
 
+def runtime_api_json(
+    runtime_state: dict,
+    namespace: str,
+    method: str,
+    path: str,
+    body: dict | None,
+    label: str,
+    timeout: int = 60,
+) -> dict:
+    """Call the public Runtime API for development inputs not yet exposed by the pinned CLI."""
+    base_url = str(runtime_state["runtimeUrl"]).rstrip("/")
+    request_body = json.dumps(body).encode("utf-8") if body is not None else None
+    headers = {
+        "Accept": "application/json",
+        "Content-Type": "application/json",
+        "X-NS": namespace,
+    }
+    auth_code = os.environ.get("FOGGY_RUNTIME_API_AUTH_CODE")
+    if auth_code:
+        headers["X-Foggy-Runtime-Code"] = auth_code
+    request = urllib.request.Request(
+        f"{base_url}{path}",
+        data=request_body,
+        headers=headers,
+        method=method,
+    )
+    try:
+        with urllib.request.urlopen(request, timeout=timeout) as response:
+            raw = response.read().decode("utf-8", errors="replace")
+    except urllib.error.HTTPError as exc:
+        raw = exc.read().decode("utf-8", errors="replace")
+        try:
+            failed = json.loads(raw)
+        except json.JSONDecodeError:
+            failed = None
+        error = failed.get("error") if isinstance(failed, dict) else None
+        detail = (
+            " | ".join(str(error.get(name)) for name in ("code", "phase", "message") if error.get(name))
+            if isinstance(error, dict)
+            else str(exc.reason)
+        )
+        raise OnboardingError(f"{label} failed with HTTP {exc.code}: {detail or exc.reason}") from exc
+    except urllib.error.URLError as exc:
+        raise OnboardingError(f"{label} could not reach Runtime: {exc.reason}") from exc
+    try:
+        payload = json.loads(raw)
+    except json.JSONDecodeError as exc:
+        raise OnboardingError(f"{label} did not return JSON") from exc
+    if payload.get("success") is not True:
+        error = payload.get("error")
+        if isinstance(error, dict):
+            detail = " | ".join(str(error.get(name)) for name in ("code", "phase", "message") if error.get(name))
+        else:
+            detail = str(error or "unknown Runtime error")
+        raise OnboardingError(f"{label} returned success=false: {detail}")
+    return payload
+
+
 CONNECTION_SECRET_KEYS = {
     "jdbcurl", "url", "username", "password", "passwordenv", "passwordref",
 }
@@ -1837,7 +1912,8 @@ def onboarding_plan_command(args: argparse.Namespace) -> dict:
     if not project_root.is_dir():
         raise OnboardingError(f"Project root not found: {project_root}")
     connection_file = normalized(args.connection_file)
-    connection = validate_connection(read_json_object(connection_file, "Connection plan"))
+    requested_connection = validate_connection(read_json_object(connection_file, "Connection plan"))
+    connection = persisted_connection(requested_connection)
     if connection.get("connectionMode") == "opaque-profile":
         require_opaque_profile_cli(install_state)
     existing = read_onboarding_state(data_root, profile, required=False)
@@ -1882,7 +1958,10 @@ def onboarding_plan_command(args: argparse.Namespace) -> dict:
         "schemaVersion": "foggy-deepseek-onboarding-plan-result/v1",
         "profile": profile,
         "statePath": str(path),
-        "connection": {**connection, "passwordEnvPresent": bool(password_env and os.environ.get(password_env))},
+        "connection": {
+            **connection,
+            "passwordEnvPresent": bool(password_env and os.environ.get(password_env)),
+        },
         "runtimeAvailable": runtime_state is not None,
         "next": "run datasource-configure --apply after reviewing the plan",
         "productionReady": False,
@@ -1913,10 +1992,11 @@ def datasource_configure_command(args: argparse.Namespace) -> dict:
     if opaque:
         plan.update({"profileId": connection["opaqueProfileId"], "revision": connection["opaqueRevision"]})
     else:
+        inline_password = getattr(args, "runtime_password", None)
         plan.update({
             "jdbcUrl": connection["jdbcUrl"],
             "username": connection.get("username"),
-            "passwordEnv": connection.get("passwordEnv"),
+            "credentialMode": connection.get("credentialMode", "none"),
         })
     if not args.apply:
         return {"success": True, "dryRun": True, "profile": state["profile"], "plan": plan, "next": "rerun with --apply after approval"}
@@ -1928,22 +2008,50 @@ def datasource_configure_command(args: argparse.Namespace) -> dict:
         ]
         label = "opaque profile configure"
     else:
+        inline_password = getattr(args, "runtime_password", None)
         password_env = connection.get("passwordEnv")
-        if password_env and not os.environ.get(password_env):
+        if connection.get("credentialMode") == "inline-development" and inline_password is None:
+            raise OnboardingError(
+                "Direct development password is not persisted; rerun onboard-datasource-run with the original connection file"
+            )
+        if inline_password is None and password_env and os.environ.get(password_env) is None:
             raise OnboardingError(f"Required password environment variable is not present: {password_env}")
-        command = ["datasources", "add", "--name", connection["name"], "--type", connection["type"], "--jdbc-url", connection["jdbcUrl"]]
-        if connection.get("username"):
-            command.extend(["--username", connection["username"]])
-        if password_env:
-            command.extend(["--password-env", password_env])
         label = "datasources add"
-    if args.replace:
-        command.append("--replace")
+        resolved_password = inline_password if inline_password is not None else (
+            os.environ.get(password_env) if password_env else None
+        )
+        command = None
     already_present = False
     try:
-        result = redact_connection_material(
-            cli_json(install_state, runtime_state, connection["namespace"], command, label)
-        )
+        if not opaque and resolved_password is not None:
+            body = {
+                "name": connection["name"],
+                "type": connection["type"],
+                "jdbcUrl": connection["jdbcUrl"],
+                "replace": bool(args.replace),
+                "enabled": True,
+                "password": resolved_password,
+            }
+            if connection.get("username"):
+                body["username"] = connection["username"]
+            result = redact_connection_material(runtime_api_json(
+                runtime_state,
+                connection["namespace"],
+                "POST",
+                "/api/v1/datasources",
+                body,
+                label,
+            ))
+        else:
+            if not opaque:
+                command = ["datasources", "add", "--name", connection["name"], "--type", connection["type"], "--jdbc-url", connection["jdbcUrl"]]
+                if connection.get("username"):
+                    command.extend(["--username", connection["username"]])
+            if args.replace:
+                command.append("--replace")
+            result = redact_connection_material(
+                cli_json(install_state, runtime_state, connection["namespace"], command, label)
+            )
     except OnboardingError as exc:
         if "DATASOURCE_ALREADY_EXISTS" not in str(exc):
             raise
@@ -2641,6 +2749,7 @@ def datasource_run_command(args: argparse.Namespace) -> dict:
     _install_root, install_state, data_root, _runtime_state = onboarding_context(args, require_runtime=True)
     project_root = normalized(args.project_root or Path.cwd())
     requested_connection = validate_connection(read_json_object(normalized(args.connection_file), "Connection plan"))
+    resumable_connection = persisted_connection(requested_connection)
     if not requested_connection.get("profile"):
         raise OnboardingError("Composite datasource onboarding requires connection.profile in the approved contract")
     profile = requested_connection["profile"]
@@ -2654,7 +2763,7 @@ def datasource_run_command(args: argparse.Namespace) -> dict:
     files: list[str] = []
     existing = read_onboarding_state(data_root, profile, required=False)
     if existing:
-        if existing.get("connection") != requested_connection:
+        if persisted_connection(existing.get("connection", {})) != resumable_connection:
             raise OnboardingError("Existing onboarding profile does not match the requested connection plan")
         adopted = bind_completed_workspace(existing, data_root, project_root)
         plan_result = {
@@ -2687,6 +2796,7 @@ def datasource_run_command(args: argparse.Namespace) -> dict:
     else:
         configure_dry = datasource_configure_command(argparse.Namespace(
             install_root=args.install_root, data_root=args.data_root, profile=profile, apply=False, replace=False,
+            runtime_password=requested_connection.get("password"),
         ))
         save_composite_result(evidence_dir, "02-datasource-dry.json", configure_dry, files)
         if not args.approve_configure:
@@ -2702,6 +2812,7 @@ def datasource_run_command(args: argparse.Namespace) -> dict:
             }
         configured = datasource_configure_command(argparse.Namespace(
             install_root=args.install_root, data_root=args.data_root, profile=profile, apply=True, replace=False,
+            runtime_password=requested_connection.get("password"),
         ))
         save_composite_result(evidence_dir, "03-datasource-apply.json", configured, files)
         state = read_onboarding_state(data_root, profile)