@delta-infra/cli 1.1.19 → 1.1.21

package/skills/delta-science/references/antbo.md

@@ -1,105 +1,105 @@
-# AntBO reference
-
-Use `delta-cli science invoke` with `endpoint`, `data` and `params`. Read business results
-from the CLI response fields defined in this document. Run operations marked as mutating only
-with the user's explicit authorisation, and never retry them.
-
-For antibody/CDRH3 tasks, do not switch to small-molecule LDM-BO or STRBO even if the user
-mentions “LDM”. The current catalogue exposes both CDRH3 generation, suggestion and evaluation
-operations and the traditional AntBO job-management operations.
-
-## health (read-only)
-
-- Use case: Check whether the remote AntBO environment is available.
-- Request: `endpoint="health"; data=None; params=None`
-- Read from the response: `status`, `antbo_available`, `metadata`, `limits` and `warnings`.
-
-## run-default-job (mutating)
-
-- Use case: The user explicitly asks to start the standard background continuation job.
-- Request: `endpoint="run-default-job"; data=None; params={"log_name":"antbo_<unique-timestamp>.log","append":False,"timeout_seconds":86400}`
-- Read from the response: `started`, `pid`, `log_name` or `log_path`, and `timeout_seconds`. Do not retry if the outcome is unknown.
-
-Report the job as started only when the same business response contains `started=true`, a
-non-empty `pid`, and either `log_name` or `log_path`. If any field is missing, mark the start
-as unverified and do not submit again.
-
-## run (heavy, mutating)
-
-- Use case: The user explicitly supplies an approved AntBO script, configuration and antigen file, and asks for synchronous execution.
-- Request: `endpoint="run"; data={"script_path":"./bo/main.py","config_path":"./bo/config.yaml","n_trials":1,"seed":42,"antigens_file":"<path within project root>","extra_args":[],"timeout_seconds":86400,"cuda_visible_devices":"0","conda_env":"DGM","log_name":"antbo_custom.log","append":False}; params=None`
-- Read from the response: `ok`, `returncode`, `timed_out`, `log_path` and whether the log was truncated. Do not include the full log in the final reply.
-
-## log (read-only)
-
-- Use case: The user provides a known `log_name` and asks to inspect the end of the log.
-- Request: `endpoint="log"; data=None; params={"log_name":"antbo_run.log"}`
-- Read from the response: `log_name`, `log` and `log_truncated`. For long logs, provide only a bounded summary of the tail.
-
-## jobs (read-only)
-
-- Use case: List the active jobs registered by the current service container.
-- Request: `endpoint="jobs"; data=None; params=None`
-- Read `pid`, `running`, `returncode`, `log_name` and `log_path` from each item in `jobs`.
-
-## stop (mutating)
-
-- Use case: The user explicitly asks to stop a job with a confirmed PID.
-- Request: `endpoint="stop"; data=None; params={"pid":12345}`
-- Read from the response: `stopped`, `pid` and `message`. Do not retry blindly or call without parameters when multiple jobs exist.
-
-## CDRH3 generation and optimisation
-
-The server's supported antigens are defined by `supported_antigens` in the health response.
-Do not guess or treat an arbitrary protein-file path as an antigen. Deployments commonly support
-`1ADQ_A`, `1FBI_X`, `1H0D_C`, `1NSN_S` and `1OB1_C`, but use the current service response
-and the user's choice before execution.
-
-### ldm-health (read-only)
-
-- Request: `endpoint="ldm-health"; data=None; params=None`
-- Read from the response: `supported_antigens`, `cdrh3_length`, `objective`, and fields describing Absolut/model provenance.
-
-### ldm-init / ldm-init-validate
-
-```json
-{
-  "task": "Generate initial CDRH3 candidates for the specified antigen",
-  "num_initial": 3,
-  "antigen": "1ADQ_A",
-  "seed": 42
-}
-```
-
-Use `ldm-init-validate` only to validate parameters; use `ldm-init` for generation. Successful
-candidates must be CDRH3 sequences returned by the service. Do not invent candidates.
-
-### ldm-suggest / ldm-suggest-validate
-
-```json
-{
-  "task": "Continue reducing antigen binding energy",
-  "history_xs": ["ARVGYSLYAMD", "AKYGGYDYAMD"],
-  "history_ys": [-18.2, -17.4],
-  "num_suggestions": 2,
-  "antigen": "1ADQ_A",
-  "seed": 42
-}
-```
-
-AntBO is single-objective. `history_ys` must be a one-dimensional array of finite numbers and
-have the same length as `history_xs`. Each CDRH3 must contain 11 standard amino-acid characters;
-use the current `cdrh3_length` returned by `ldm-health` as the final constraint.
-
-### evaluate / evaluate-validate
-
-```json
-{
-  "designs": ["ARVGYSLYAMD", "AKYGGYDYAMD"],
-  "antigen": "1ADQ_A"
-}
-```
-
-The number of returned scores must match the number of designs; lower binding energy is better.
-Generation, suggestion and evaluation are all heavy remote calls. Do not retry if the outcome is
-unknown or times out, and do not fill in results with locally generated random scores.
+# AntBO reference
+
+Use `delta-cli science invoke` with `endpoint`, `data` and `params`. Read business results
+from the CLI response fields defined in this document. Run operations marked as mutating only
+with the user's explicit authorisation, and never retry them.
+
+For antibody/CDRH3 tasks, do not switch to small-molecule LDM-BO or STRBO even if the user
+mentions “LDM”. The current catalogue exposes both CDRH3 generation, suggestion and evaluation
+operations and the traditional AntBO job-management operations.
+
+## health (read-only)
+
+- Use case: Check whether the remote AntBO environment is available.
+- Request: `endpoint="health"; data=None; params=None`
+- Read from the response: `status`, `antbo_available`, `metadata`, `limits` and `warnings`.
+
+## run-default-job (mutating)
+
+- Use case: The user explicitly asks to start the standard background continuation job.
+- Request: `endpoint="run-default-job"; data=None; params={"log_name":"antbo_<unique-timestamp>.log","append":False,"timeout_seconds":86400}`
+- Read from the response: `started`, `pid`, `log_name` or `log_path`, and `timeout_seconds`. Do not retry if the outcome is unknown.
+
+Report the job as started only when the same business response contains `started=true`, a
+non-empty `pid`, and either `log_name` or `log_path`. If any field is missing, mark the start
+as unverified and do not submit again.
+
+## run (heavy, mutating)
+
+- Use case: The user explicitly supplies an approved AntBO script, configuration and antigen file, and asks for synchronous execution.
+- Request: `endpoint="run"; data={"script_path":"./bo/main.py","config_path":"./bo/config.yaml","n_trials":1,"seed":42,"antigens_file":"<path within project root>","extra_args":[],"timeout_seconds":86400,"cuda_visible_devices":"0","conda_env":"DGM","log_name":"antbo_custom.log","append":False}; params=None`
+- Read from the response: `ok`, `returncode`, `timed_out`, `log_path` and whether the log was truncated. Do not include the full log in the final reply.
+
+## log (read-only)
+
+- Use case: The user provides a known `log_name` and asks to inspect the end of the log.
+- Request: `endpoint="log"; data=None; params={"log_name":"antbo_run.log"}`
+- Read from the response: `log_name`, `log` and `log_truncated`. For long logs, provide only a bounded summary of the tail.
+
+## jobs (read-only)
+
+- Use case: List the active jobs registered by the current service container.
+- Request: `endpoint="jobs"; data=None; params=None`
+- Read `pid`, `running`, `returncode`, `log_name` and `log_path` from each item in `jobs`.
+
+## stop (mutating)
+
+- Use case: The user explicitly asks to stop a job with a confirmed PID.
+- Request: `endpoint="stop"; data=None; params={"pid":12345}`
+- Read from the response: `stopped`, `pid` and `message`. Do not retry blindly or call without parameters when multiple jobs exist.
+
+## CDRH3 generation and optimisation
+
+The server's supported antigens are defined by `supported_antigens` in the health response.
+Do not guess or treat an arbitrary protein-file path as an antigen. Deployments commonly support
+`1ADQ_A`, `1FBI_X`, `1H0D_C`, `1NSN_S` and `1OB1_C`, but use the current service response
+and the user's choice before execution.
+
+### ldm-health (read-only)
+
+- Request: `endpoint="ldm-health"; data=None; params=None`
+- Read from the response: `supported_antigens`, `cdrh3_length`, `objective`, and fields describing Absolut/model provenance.
+
+### ldm-init / ldm-init-validate
+
+```json
+{
+  "task": "Generate initial CDRH3 candidates for the specified antigen",
+  "num_initial": 3,
+  "antigen": "1ADQ_A",
+  "seed": 42
+}
+```
+
+Use `ldm-init-validate` only to validate parameters; use `ldm-init` for generation. Successful
+candidates must be CDRH3 sequences returned by the service. Do not invent candidates.
+
+### ldm-suggest / ldm-suggest-validate
+
+```json
+{
+  "task": "Continue reducing antigen binding energy",
+  "history_xs": ["ARVGYSLYAMD", "AKYGGYDYAMD"],
+  "history_ys": [-18.2, -17.4],
+  "num_suggestions": 2,
+  "antigen": "1ADQ_A",
+  "seed": 42
+}
+```
+
+AntBO is single-objective. `history_ys` must be a one-dimensional array of finite numbers and
+have the same length as `history_xs`. Each CDRH3 must contain 11 standard amino-acid characters;
+use the current `cdrh3_length` returned by `ldm-health` as the final constraint.
+
+### evaluate / evaluate-validate
+
+```json
+{
+  "designs": ["ARVGYSLYAMD", "AKYGGYDYAMD"],
+  "antigen": "1ADQ_A"
+}
+```
+
+The number of returned scores must match the number of designs; lower binding energy is better.
+Generation, suggestion and evaluation are all heavy remote calls. Do not retry if the outcome is
+unknown or times out, and do not fill in results with locally generated random scores.

package/skills/delta-science/references/delta-bo.md

@@ -1,92 +1,92 @@
-# Delta-BO reference
-
-Make all online calls with `delta-cli science invoke`; the tool is always `delta-bo`. The current
-CLI catalogue exposes only `commands` and `generate`. Do not infer operations from old HTTP
-documentation or call the stateful command API directly.
-
-## commands
-
-Use case: The user asks which Delta-BO commands are supported by the current deployment.
-
-```text
-delta-cli science invoke --tool delta-bo --endpoint commands
-```
-
-No request body. Report only the command list in the current business response; do not fill it in from historical documentation.
-
-## generate
-
-Use case: Generate random-search or Bayesian-optimisation suggestions for numeric, integer or categorical experimental variables.
-
-When there is no real history, or fewer than five historical observations and the user has not explicitly requested BO, use bounded random search:
-
-```json
-{
-  "params": [
-    {"name": "x", "type": "numeric", "low": 0.0, "high": 1.0}
-  ],
-  "num_suggestions": 3,
-  "algorithm": "random-search",
-  "seed": 42
-}
-```
-
-When real history is available and the user explicitly requests BO, you may use:
-
-```json
-{
-  "params": [
-    {"name": "temperature", "type": "numeric", "low": 20.0, "high": 120.0},
-    {"name": "catalyst", "type": "categorical", "choices": ["A", "B", "C"]}
-  ],
-  "objectives": [{"name": "yield", "minimize": false}],
-  "num_suggestions": 2,
-  "algorithm": "bo",
-  "model": {"name": "gp", "min_samples": 2, "train_steps": 50},
-  "acq_target": {"name": "ucb", "beta": 2.0},
-  "solver": {"name": "ga", "pop_size": 40, "n_gen": 10},
-  "histories": {
-    "decisions": [
-      {"temperature": 40.0, "catalyst": "A"},
-      {"temperature": 80.0, "catalyst": "B"}
-    ],
-    "observations": [
-      {"yield": 0.42},
-      {"yield": 0.61}
-    ]
-  },
-  "seed": 7
-}
-```
-
-Supported parameter types are `numeric`, `integer` and `categorical`. Prefer object-form history
-to avoid ambiguity about the order of array columns. Do not invent observations, objective values
-or purported optima.
-
-Optional deduplication and constraints:
-
-```json
-{
-  "diversity": {
-    "deduplicate": true,
-    "min_numeric_distance": {"temperature": 5.0},
-    "prefer_unique_categories": true
-  },
-  "constraints": [
-    {"type": "unique_batch"},
-    {"type": "avoid_seen_decisions"}
-  ]
-}
-```
-
-Report only fields actually present in the business response: `suggestions`,
-`suggestion_metadata`, `warnings`, `generated_candidate_count` and `diversity`. Do not replace
-empty suggestions or a failure with local GP, UCB or random-number results.
-
-## Known legacy capabilities that are not exposed
-
-The old service included stateful commands such as session, space, objective, policy, suggest,
-observe, loop, status and best, but they are not current Delta CLI operations. This Skill records
-only that capability boundary: it includes no URL or curl examples and does not run those
-operations. To extend the interface, first expose the operation and request schema through Science
-Server, then update this reference.
+# Delta-BO reference
+
+Make all online calls with `delta-cli science invoke`; the tool is always `delta-bo`. The current
+CLI catalogue exposes only `commands` and `generate`. Do not infer operations from old HTTP
+documentation or call the stateful command API directly.
+
+## commands
+
+Use case: The user asks which Delta-BO commands are supported by the current deployment.
+
+```text
+delta-cli science invoke --tool delta-bo --endpoint commands
+```
+
+No request body. Report only the command list in the current business response; do not fill it in from historical documentation.
+
+## generate
+
+Use case: Generate random-search or Bayesian-optimisation suggestions for numeric, integer or categorical experimental variables.
+
+When there is no real history, or fewer than five historical observations and the user has not explicitly requested BO, use bounded random search:
+
+```json
+{
+  "params": [
+    {"name": "x", "type": "numeric", "low": 0.0, "high": 1.0}
+  ],
+  "num_suggestions": 3,
+  "algorithm": "random-search",
+  "seed": 42
+}
+```
+
+When real history is available and the user explicitly requests BO, you may use:
+
+```json
+{
+  "params": [
+    {"name": "temperature", "type": "numeric", "low": 20.0, "high": 120.0},
+    {"name": "catalyst", "type": "categorical", "choices": ["A", "B", "C"]}
+  ],
+  "objectives": [{"name": "yield", "minimize": false}],
+  "num_suggestions": 2,
+  "algorithm": "bo",
+  "model": {"name": "gp", "min_samples": 2, "train_steps": 50},
+  "acq_target": {"name": "ucb", "beta": 2.0},
+  "solver": {"name": "ga", "pop_size": 40, "n_gen": 10},
+  "histories": {
+    "decisions": [
+      {"temperature": 40.0, "catalyst": "A"},
+      {"temperature": 80.0, "catalyst": "B"}
+    ],
+    "observations": [
+      {"yield": 0.42},
+      {"yield": 0.61}
+    ]
+  },
+  "seed": 7
+}
+```
+
+Supported parameter types are `numeric`, `integer` and `categorical`. Prefer object-form history
+to avoid ambiguity about the order of array columns. Do not invent observations, objective values
+or purported optima.
+
+Optional deduplication and constraints:
+
+```json
+{
+  "diversity": {
+    "deduplicate": true,
+    "min_numeric_distance": {"temperature": 5.0},
+    "prefer_unique_categories": true
+  },
+  "constraints": [
+    {"type": "unique_batch"},
+    {"type": "avoid_seen_decisions"}
+  ]
+}
+```
+
+Report only fields actually present in the business response: `suggestions`,
+`suggestion_metadata`, `warnings`, `generated_candidate_count` and `diversity`. Do not replace
+empty suggestions or a failure with local GP, UCB or random-number results.
+
+## Known legacy capabilities that are not exposed
+
+The old service included stateful commands such as session, space, objective, policy, suggest,
+observe, loop, status and best, but they are not current Delta CLI operations. This Skill records
+only that capability boundary: it includes no URL or curl examples and does not run those
+operations. To extend the interface, first expose the operation and request schema through Science
+Server, then update this reference.

package/skills/delta-science/references/gsasii.md

@@ -1,118 +1,118 @@
-# GSAS-II reference
-
-Make all calls with `delta-cli science invoke`. Simulation requires a real CIF; refinement
-requires real powder data, instrument parameters and phase CIFs. Never fill in a failed result
-with synthetic data. If the input is not a CIF, first use a successful pymatgen
-`structure-convert` result from the current task.
-
-## Health
-
-Operation: `health`; no request body.
-
-Key response fields in `data`: `status`, `service`, `gsasii_available`,
-`metadata`, and `limits`.
-
-Call this only when the user explicitly asks for a health check; do not add a health call automatically before simulation or refinement.
-
-## Powder Simulation
-
-Operation: `powder-simulate`.
-
-```json
-{
-  "cif": "<CIF text>",
-  "phase_name": "phase",
-  "instrument_parameters": "<GSAS-II instrument parameter text>",
-  "histogram_name": "simulation",
-  "t_min": 10.0,
-  "t_max": 80.0,
-  "t_step": 0.02,
-  "include_profile": true,
-  "max_profile_points": 1000,
-  "include_reflections": true,
-  "max_reflections": 1000,
-  "return_refined_cif": false,
-  "return_project": false
-}
-```
-
-Use either `t_step` or `n_points`, not both. Optional fields include
-`wavelength`, `radiation`, `scale`, `include_profile`, `max_profile_points`,
-`include_reflections`, `max_reflections`, `return_refined_cif`, and
-`return_project`.
-
-The response includes `profile` points with `x`, `y_calc`, optional background,
-bounded `reflections` with hkl/d-spacing/2theta where available, and metadata.
-If `return_project` is true, `project_base64` contains the GSAS-II `.gpx`
-project. If `return_refined_cif` is true, `refined_cif` contains exported CIF
-text for pymatgen handoff when GSAS-II supports export for the phase.
-
-Notes:
-
-- `cif` should be valid CIF text. If the input is POSCAR/JSON/CSSR/XSF, use
-  pymatgen `structure-convert` first with `output_format: "cif"`.
-- `instrument_parameters` should be GSAS-II instrument parameter text such as
-  `INST_XRY.PRM` when instrument-specific simulation is needed.
-- For quick simulation only, `instrument_parameters` may be omitted. The service
-  then generates a simple CW X-ray instrument model from `wavelength` or
-  `radiation` (`CuKa` by default; also supports aliases such as `MoKa`, `CoKa`,
-  `CrKa`, and explicit numeric wavelength).
-- Refinement still requires real `instrument_parameters`.
-- `max_profile_points` controls response sampling. Use small values for smoke
-  tests and larger values for profile comparison.
-- Older deployed gateway images may require `max_profile_points >= 10`.
-
-## Powder Refinement
-
-Operation: `powder-refine`.
-
-```json
-{
-  "powder_data": "<two-column or three-column powder data text>",
-  "powder_format": "xy",
-  "instrument_parameters": "<GSAS-II instrument parameter text>",
-  "phases": [
-    {"name": "phase", "cif": "<CIF text>"}
-  ],
-  "refinement_mode": "rietveld",
-  "refinement_steps": [],
-  "max_cycles": 3,
-  "histogram_name": "powder",
-  "include_profile": true,
-  "max_profile_points": 1000,
-  "include_reflections": true,
-  "max_reflections": 1000,
-  "return_refined_cif": false,
-  "return_project": false
-}
-```
-
-Supported `powder_format` values: `xy`, `xye`, `fxye`, `gsas`, and `csv`.
-
-`refinement_mode: "rietveld"` is currently implemented. `pawley` and `lebail`
-return a clear not-implemented response until the service wires the
-mode-specific GSAS-II setup.
-
-The response includes fit `residuals` when available, phase summaries, sampled
-profile points, bounded `reflections`, warnings, optional `refined_cif`, and
-the optional `.gpx` project.
-
-Notes:
-
-- Use `xy` for simple whitespace-delimited `x y` rows, `xye` for `x y esd`,
-  `csv` for numeric comma-separated rows, or `gsas`/`fxye` for GSAS-like powder
-  formats.
-- `max_cycles: 0` is useful for project-construction smoke tests. Increase it
-  only when the powder data, phase model, instrument file, and refinement steps
-  are realistic.
-- `refinement_steps` is passed to `G2Project.do_refinements`. Keep recipes
-  incremental and inspect `warnings`, `residuals`, and `lst` output.
-- Refinement may return `valid: false` with partial phase/profile information
-  if GSAS-II constructed the project but a refinement step failed.
-
-## Cross-tool hand-off
-
-Complete structure conversion, diffraction simulation and refinement step by step through the
-CLI within this Skill: `pymatgen structure-convert -> gsasii powder-simulate/powder-refine`.
-Use downstream only the structure text or profile from the preceding successful business response;
-do not run local scripts or call the service directly.
+# GSAS-II reference
+
+Make all calls with `delta-cli science invoke`. Simulation requires a real CIF; refinement
+requires real powder data, instrument parameters and phase CIFs. Never fill in a failed result
+with synthetic data. If the input is not a CIF, first use a successful pymatgen
+`structure-convert` result from the current task.
+
+## Health
+
+Operation: `health`; no request body.
+
+Key response fields in `data`: `status`, `service`, `gsasii_available`,
+`metadata`, and `limits`.
+
+Call this only when the user explicitly asks for a health check; do not add a health call automatically before simulation or refinement.
+
+## Powder Simulation
+
+Operation: `powder-simulate`.
+
+```json
+{
+  "cif": "<CIF text>",
+  "phase_name": "phase",
+  "instrument_parameters": "<GSAS-II instrument parameter text>",
+  "histogram_name": "simulation",
+  "t_min": 10.0,
+  "t_max": 80.0,
+  "t_step": 0.02,
+  "include_profile": true,
+  "max_profile_points": 1000,
+  "include_reflections": true,
+  "max_reflections": 1000,
+  "return_refined_cif": false,
+  "return_project": false
+}
+```
+
+Use either `t_step` or `n_points`, not both. Optional fields include
+`wavelength`, `radiation`, `scale`, `include_profile`, `max_profile_points`,
+`include_reflections`, `max_reflections`, `return_refined_cif`, and
+`return_project`.
+
+The response includes `profile` points with `x`, `y_calc`, optional background,
+bounded `reflections` with hkl/d-spacing/2theta where available, and metadata.
+If `return_project` is true, `project_base64` contains the GSAS-II `.gpx`
+project. If `return_refined_cif` is true, `refined_cif` contains exported CIF
+text for pymatgen handoff when GSAS-II supports export for the phase.
+
+Notes:
+
+- `cif` should be valid CIF text. If the input is POSCAR/JSON/CSSR/XSF, use
+  pymatgen `structure-convert` first with `output_format: "cif"`.
+- `instrument_parameters` should be GSAS-II instrument parameter text such as
+  `INST_XRY.PRM` when instrument-specific simulation is needed.
+- For quick simulation only, `instrument_parameters` may be omitted. The service
+  then generates a simple CW X-ray instrument model from `wavelength` or
+  `radiation` (`CuKa` by default; also supports aliases such as `MoKa`, `CoKa`,
+  `CrKa`, and explicit numeric wavelength).
+- Refinement still requires real `instrument_parameters`.
+- `max_profile_points` controls response sampling. Use small values for smoke
+  tests and larger values for profile comparison.
+- Older deployed gateway images may require `max_profile_points >= 10`.
+
+## Powder Refinement
+
+Operation: `powder-refine`.
+
+```json
+{
+  "powder_data": "<two-column or three-column powder data text>",
+  "powder_format": "xy",
+  "instrument_parameters": "<GSAS-II instrument parameter text>",
+  "phases": [
+    {"name": "phase", "cif": "<CIF text>"}
+  ],
+  "refinement_mode": "rietveld",
+  "refinement_steps": [],
+  "max_cycles": 3,
+  "histogram_name": "powder",
+  "include_profile": true,
+  "max_profile_points": 1000,
+  "include_reflections": true,
+  "max_reflections": 1000,
+  "return_refined_cif": false,
+  "return_project": false
+}
+```
+
+Supported `powder_format` values: `xy`, `xye`, `fxye`, `gsas`, and `csv`.
+
+`refinement_mode: "rietveld"` is currently implemented. `pawley` and `lebail`
+return a clear not-implemented response until the service wires the
+mode-specific GSAS-II setup.
+
+The response includes fit `residuals` when available, phase summaries, sampled
+profile points, bounded `reflections`, warnings, optional `refined_cif`, and
+the optional `.gpx` project.
+
+Notes:
+
+- Use `xy` for simple whitespace-delimited `x y` rows, `xye` for `x y esd`,
+  `csv` for numeric comma-separated rows, or `gsas`/`fxye` for GSAS-like powder
+  formats.
+- `max_cycles: 0` is useful for project-construction smoke tests. Increase it
+  only when the powder data, phase model, instrument file, and refinement steps
+  are realistic.
+- `refinement_steps` is passed to `G2Project.do_refinements`. Keep recipes
+  incremental and inspect `warnings`, `residuals`, and `lst` output.
+- Refinement may return `valid: false` with partial phase/profile information
+  if GSAS-II constructed the project but a refinement step failed.
+
+## Cross-tool hand-off
+
+Complete structure conversion, diffraction simulation and refinement step by step through the
+CLI within this Skill: `pymatgen structure-convert -> gsasii powder-simulate/powder-refine`.
+Use downstream only the structure text or profile from the preceding successful business response;
+do not run local scripts or call the service directly.