[flutter_conductor] Update conductor readme (#94950)

* update

* more

dev/conductor/README.md

@@ -15,6 +15,14 @@ Some basic requirements to conduct a release are:
   [framework](https://github.com/flutter/flutter) and
   [engine](https://github.com/flutter/engine) repositories.
 
+For the best experience, it is recommended to use ssh protocol for connecting to
+GitHub remote repositories (i.e. for `--framework-mirror` and `--engine-mirror`
+specify the remote with the format `git@github.com:username/reponame`). If your
+local ssh key is password-protected, it is recommended to use ssh-agent to
+unlock your ssh key for the session; if you do not, each time the conductor
+attempts to interact with a remote, the user will be prompted to enter their ssh
+key password.
+
 ## Usage
 
 The main entrypoint for the conductor is [bin/conductor](bin/conductor). For
@@ -41,11 +49,17 @@ conductor start \
 
 For more details on these command line arguments, see `conductor help start`.
 This command will write to disk a state file that will persist until the release
-is completed. To see the current status of the release (at any time), issue the
-command:
+is completed. If you already have a persistent state file, this command will
+fail with an error message. To see the current status of the release (at any
+time), issue the command:
 
 `conductor status`
 
+To delete a persistent state file (either because the release was successfully
+completed or abandoned), use the command:
+
+`conductor clean`
+
 Once initializing the release, the conductor tool will issue instructions for
 manual steps that must be executed by the user. At any time these instructions
 can be seen via `conductor status`. Once these manual steps have been completed,
@@ -53,11 +67,6 @@ you can proceed to the next step by using the command:
 
 `conductor next`
 
-Upon successful completion of the release, the following command will remove the
-persistent state file:
-
-`conductor clean`
-
 ## Steps
 
 Once the user has finished manual steps for each step, they proceed to the next
@@ -95,15 +104,19 @@ $REVISION`) and resolve the merge conflict in their checkout.
 ### Publish Version
 
 This step will add a version git tag to the final Framework commit and push it
-to the upstream repository.
+to the upstream repository. The presence of a tag affects what the flutter CLI
+tool reports the current version is.
 
 ### Publish Channel
 
 This step will push the Framework candidate branch to the upstream release
-branch.
+branch (e.g. the `stable` branch). Once this push happens upstream, the release
+has officially been published, and the code will be available to existing
+Flutter users via `flutter upgrade`.
 
 ### Verify Release
 
 For the final step, the user must manually verify that packaging builds have
-finished successfully. The conductor will produce links to the dashboards for
-monitoring CI builds.
+finished successfully. The SDK compressed archives will not be available from
+the website until the packaging build has finished. The conductor will produce
+links to the dashboards for monitoring CI builds.