npm - @foggy-projects/deepseek-harness-plugin - Versions diffs - 0.4.0-beta.14 → 0.4.0-beta.16 - Mend

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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (14) hide show

package/README.md CHANGED Viewed

@@ -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.16.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 CHANGED Viewed

@@ -1,10 +1,10 @@
-# Public beta readiness: 0.4.0-beta.14
+# Public beta readiness: 0.4.0-beta.16
-Assessment date: 2026-09-04
+Assessment date: 2026-09-05
 ## Verdict
-`0.4.0-beta.14` is suitable for a scoped public beta on Windows 10/11 x64 and
+`0.4.0-beta.16` 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,24 @@ 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.
-- 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.
+- 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 package and settings contract report Python 3.12.13 as `Foggy private`,
+  CLI 0.1.23, Launcher 0.1.18, analysis Skill 0.1.17, and onboarding Skill
+  0.4.0-beta.16; the same component display was accepted in the preceding
+  native Windows beta run.
 - 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 +63,14 @@ 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 23 Python tests. The
+  new datasource tests cover secret-free persisted state, direct Runtime API
+  submission, CLI bypass for inline development credentials, stable inline
+  credential resumption, bounded transient connection retry, and output redaction.
+- A real Java 17 / Launcher 0.1.18 regression resumed the same completed inline
+  datasource composite twice, retained the Runtime PID, and emitted a complete
+  `01` through `06` workspace evidence sequence without falling back to granular
+  commands.
 ## Beta boundaries
@@ -63,6 +85,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 CHANGED Viewed

@@ -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.16` 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.16;
 - 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 CHANGED Viewed

@@ -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.16"
 PLUGIN_REF="v${PLUGIN_VERSION}"
 PLUGIN_REPOSITORY="https://github.com/foggy-projects/foggy-deepseek-harness-plugin.git"

package/package.json CHANGED Viewed

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

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

@@ -1,137 +1,126 @@
 ---
 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.
+For a normal end-to-end request, take the documented composite-command path first. Do not inspect
+`onboarding.py`, enumerate CLI help, search installation directories, load the sales-drop example, or
+fetch online syntax documentation before trying that path. Use those troubleshooting or reference
+sources only when a concrete error or unsupported modeling requirement makes them relevant.
+Use the user's business terms to narrow schema discovery with `--pattern` or repeated `--table` when
+there are clear candidates. Otherwise keep the bounded default, then inspect only the few tables and
+columns needed for the requested model. Full results belong in the evidence files; retain concise
+summaries and paths in the conversation instead of repeatedly reading complete JSON artifacts.
+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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

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

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

@@ -1,156 +1,154 @@
-# 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.
+# 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"
+}
+```
-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.
+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"
+}
+```
-## Conversation contract
+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.
-Collect these non-secret values before creating a plan:
+## Normal sequence
-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.
+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:
-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.
+```text
+onboard-datasource-run --project-root <current-workspace> \
+  --connection-file <connection-json> \
+  --approve-configure --approve-bind --include-indexes
+```
-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.
+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.
-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.
+The command performs:
-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.
+```text
+datasource add -> datasource test -> namespace bind -> diagnostics
+tables list -> bounded schema inspection
+```
-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.
+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.
+Transient connection-pool readiness timeouts are retried a small, bounded number of times; invalid
+credentials, invalid URLs, and other configuration errors fail immediately.
-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.
+When the user's request clearly identifies a business subject or likely tables, add `--pattern` or
+one or more `--table` arguments so discovery remains focused. Do not enumerate CLI help, inspect the
+wrapper source, load unrelated examples, or fetch online documentation on the successful normal path.
+Keep full command payloads in the numbered evidence files and use only their concise result fields in
+the conversation.
-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/invoke-onboarding.ps1 CHANGED Viewed

@@ -26,5 +26,7 @@ if (-not $pythonCommand -or -not (Test-Path -LiteralPath $pythonCommand)) {
     exit 1
 }
+$env:PYTHONUTF8 = '1'
+$env:PYTHONIOENCODING = 'utf-8'
 & $pythonCommand (Join-Path $PSScriptRoot 'onboarding.py') @OnboardingArgs
 exit $LASTEXITCODE

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

@@ -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,24 @@ 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"}
+    credential_mode = connection.get("credentialMode")
+    if credential_mode not in {"inline-development", "agent-environment", "opaque-profile", "none"}:
+        credential_mode = (
+            "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"
+        )
+    persisted["credentialMode"] = credential_mode
+    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 +1800,108 @@ def cli_json(install_state: dict, runtime_state: dict, namespace: str, command:
     return payload
+TRANSIENT_DATASOURCE_TEST_MARKERS = (
+    "connection is not available",
+    "connection pool",
+    "request timed out",
+    "timeout waiting for connection",
+)
+def datasource_test_with_retry(
+    install_state: dict,
+    runtime_state: dict,
+    namespace: str,
+    datasource_name: str,
+    *,
+    attempts: int = 3,
+    initial_delay_seconds: float = 1.0,
+) -> dict:
+    """Retry only transient pool/readiness failures; authentication and configuration failures fail fast."""
+    for attempt in range(1, attempts + 1):
+        try:
+            result = cli_json(
+                install_state,
+                runtime_state,
+                namespace,
+                ["datasources", "test", datasource_name],
+                "datasources test",
+            )
+            if attempt > 1:
+                result = {
+                    **result,
+                    "onboardingRetry": {
+                        "attempts": attempt,
+                        "reason": "transient-datasource-readiness",
+                    },
+                }
+            return result
+        except OnboardingError as exc:
+            transient = any(marker in str(exc).lower() for marker in TRANSIENT_DATASOURCE_TEST_MARKERS)
+            if not transient or attempt == attempts:
+                raise
+            time.sleep(initial_delay_seconds * attempt)
+    raise AssertionError("unreachable")
+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 +1959,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 +2005,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 +2039,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 +2055,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
@@ -1984,9 +2139,8 @@ def datasource_verify_command(args: argparse.Namespace) -> dict:
         raise OnboardingError("Datasource is not configured; run datasource-configure --apply first")
     connection = state["connection"]
     namespace = connection["namespace"]
-    tested = redact_connection_material(cli_json(
-        install_state, runtime_state, namespace,
-        ["datasources", "test", connection["name"]], "datasources test",
+    tested = redact_connection_material(datasource_test_with_retry(
+        install_state, runtime_state, namespace, connection["name"],
     ))
     if not args.bind:
         mark_step(state, "datasourceVerified", "waiting-for-binding", connectionTested=True)
@@ -2641,6 +2795,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 +2809,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 +2842,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 +2858,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)
@@ -3314,6 +3471,10 @@ def build_parser() -> argparse.ArgumentParser:
 def main() -> None:
+    for stream in (sys.stdout, sys.stderr):
+        reconfigure = getattr(stream, "reconfigure", None)
+        if callable(reconfigure):
+            reconfigure(encoding="utf-8", errors="replace")
     args = build_parser().parse_args()
     try:
         result = args.handler(args)