<tool name="patch_experiment">
  <description>Edit an existing experiment's name, description, or metadata. In manual approval mode the browser renders an inline accept/reject card showing the experiment's current name and a before/after diff; the edit is not applied until the user accepts. Approval is skipped only when edit_permission is bypass.</description>
  <when_to_use>
    - The user asks to record an observation, note, hypothesis, or finding on an experiment after reviewing its results.
    - The user asks to rename an experiment or change its description.
  </when_to_use>
  <preflight>
    - Pass the experiment's GraphQL node ID as `experimentId`. If you do not have it, discover it first with `bash` and `phoenix-gql` rather than guessing.
    - Provide `experimentId` plus at least one field to change. Omitted fields are left untouched; pass `description: null` to clear a description.
  </preflight>
  <metadata>
    - `metadata` replaces the experiment's metadata object as a whole. There is no deep merge: any key you omit from the object you submit is dropped.
    - Before editing metadata, read the experiment's current metadata with `phoenix-gql`. Build the new object from it, preserve every unrelated key, and submit the complete object.
    - Record post-hoc findings under an `observations` array. Append a new entry `{ "at": "<ISO 8601 timestamp>", "by": "pxi", "note": "<your observation>" }` to the existing `observations` (or start the array if absent), and keep all other metadata keys — such as `hypothesis`, `changed_variable`, or `baseline_experiment_id` — exactly as they were. Do not overwrite earlier observations.
  </metadata>
  <rules>
    - Propose the edit by calling this tool directly. The inline accept/reject card is the approval surface — do not ask the user a separate yes/no question (or call `ask_user`) to confirm before calling it.
    - When edit_permission is bypass the edit applies with no card. Do not claim the experiment was updated until this tool returns an applied result; report the result the tool gives you rather than self-confirming.
    - If the tool reports that the experiment changed after the edit was proposed, re-read the experiment and propose the edit again against its current state.
  </rules>
</tool>
