dxs 0.6.0

Add an entry to componentRefs in manifest.json with the target's name, its kind and, for a package target, its module. The harness imports the generated component, and the tag, inputs and outputs are in the generated <P>.<ref>.component.ts it materializes. A hosted custom component is used through its tag only; its code stays in its own folder. Run dxs ng preview <folder> --refresh -b <branch> after a componentRefs change.

dxs ng push stores each reference as componentType plus componentConfig: the target's name, its owning application as moduleId, and a snapshot of its input and output parameters. Branch validation compares that snapshot with the live target and reports Outdated contract when a required input appears or a parameter is renamed, naming every host down to the shell. pull reads both the new and the retired shape; push writes only the new one. A reference without a snapshot is checked for existence and type only.

A new preflight, DXS-NG-056, refuses an unknown kind, a duplicate entry, a component that embeds itself, and a target that does not exist on the branch. It cannot be skipped. The server still runs its own gate on upsert, including the walk that refuses a loop through hosted components with Cyclical references detected.

A failed build is DXS-NG-057 quoting the compiler lines; no screenshot is taken. render.log is written on every run, including failures, and the dev server's output goes to .dxs-serve.log. mocks/harness-inputs.json gains a "$container" key (page, widget or dashboard-widget) so a widget-destined component previews in its real frame. The component the harness mounts is picked by name, never by file order, so a hosted copy is never edited by mistake.

dxs ng data generate walks the materialized harness, so the datasource calls of every embedded component get a "<ds>.<method>" key too. It warns when the harness predates the current componentRefs and when an entry was not materialized, which is the sign of a wrong name or module.

A widget slot is filed by its widgetType, so a custom component placed in a hub, editor or dashboard slot shows up as one. A custom component's own references are filed by componentType, and dxs source explore reverse-trace <target> lists the custom components that embed the target.

When a configuration PUT fails, the CLI releases only the lock it took for that call. It no longer asks the platform to unlock a configuration it did not lock, which the platform treats as a revert that deletes uncommitted additions and resets edits to main.

dxs auth login --remote prints a Microsoft sign-in URL and waits for the browser callback on a fixed loopback port (--callback-port, default 8400) that SSH forwards from your local computer. The remote machine keeps the PKCE verifier and stores its own credentials. The device-code flow and its --use-device-code flag are gone.

With credential_storage=file, the onboarding summary reported the persistence state wrongly. It now reflects where the credentials were written.

dxs feedback opens a short form; dxs feedback submit takes --category, --title, --message or --file, and --include-transcript for the session log. The report is saved durably before an issue is created, and dxs feedback show and retry follow a submission by its tracking id. Login is required.

Preview: the feedback service is not enabled in production yet, so a submission can fail until it is. The report stays in the local outbox, and dxs feedback retry sends it later under the same tracking id.

Groundwork on internal Datex services. Nothing in the dxs package changes.

The Release to PyPI workflow names each run after the version it publishes, so the list no longer needs the bump step's log to tell releases apart.