Note: Doc team updates the current version of the documentation and the
two previous versions (n-2), but we address *only high-priority, or
customer-reported issues* for -2 releases in support.
Describe the changes in the doc and link to your dev story:

1. - [x] Mandatory: Add the required version to the Fix version/s field.

2. - [x] Mandatory: Choose the type of documentation change or review.

• [x] We need to update to an existing topic

• [x] We need to add a new document to an existing section

• [ ] We need a whole new section; this is a function not
  documented before and doesn't belong in any current section

• [ ] We need an Operator Advisory review and approval

• [ ] We need a z-Stream (Errata) Advisory and Release note for
  MCE and/or ACM

3. - [x] Mandatory: Find the link to where the documentation update
should go and add it to the recommended changes. You can either use the
published doc or the staged repo for this step: 

Note: As the feature and doc is understood, this recommendation may
change. If this is new documentation, link to the section where you think
it should be placed.

Doc staged repo within the ACM Workspace:
https://github.com/stolostron/rhacm-docs/blob/2.14_stage/governance/manage_policies.adoc#policy-command-line-interface 

4. - [x] Mandatory for GA content:

• [x] Add steps, the diff, known issue, and/or other important
  conceptual information in the following space:

The `template-resolver` section needs to be updated to include some additional options the tool now supports. Here is the current help text, for reference:

❯ policytools template-resolver --help
Locally resolve Policy templatesUsage:
  policytools template-resolver [flags] [file|-]  The file positional argument is the path to a policy YAML manifest. If file 
  is a dash ('-') or absent, template-resolver reads from the standard input.Flags:
      --cluster-name string         the cluster name to use for the .ManagedClusterName template variable when resolving hub cluster templates
  -h, --help                        help for template-resolver
      --hub-kubeconfig string       the input kubeconfig to also resolve hub templates
      --hub-namespace string        the namespace on the hub to restrict namespaced lookups to when resolving hub templates
      --object-name string          the object namespace to use for the .ObjectName template variable when policy uses namespaceSelector or objectSelector
      --object-namespace string     the object namespace to use for the .ObjectNamespace template variable when policy uses namespaceSelector
      --save-hub-resources string   the path to save the output containing resources used in the hub cluster. This output can be used as input resources for the dry-run CLI or for local environment testing.
      --save-resources string       the path to save the output containing resources used. This output can be used as input resources for the dry-run CLI or for local environment testing.
      --skip-policy-validation      Handle the input directly as a Go template, skipping any surrounding policy field validations. 

We also need a new section for the `dryrun` subcommand which is GA in this release. Again, here's the help text for reference:

❯ policytools dryrun --help           
Locally execute a ConfigurationPolicy against input files representing the cluster state, and view the diffs and any compliance events that would be generated.Usage:
  policytools dryrun [flags]
  policytools dryrun [command]Available Commands:
  generate    Generate an API Mappings fileFlags:
  -c, --desired-status string   The desired Configuration Policy status to compare with result of the dryrun
      --full-diffs              Enable this to display the full diff in the output. By default, the number of lines is limited for readability.
  -h, --help                    help for dryrun
      --mappings-file string    An optional set of API Mappings to use. If omitted a default set will be used. A compatible file may be created by the 'generate' subcommand, and might be necessary if using custom resources. Can also be set via the DRYRUN_MAPPINGS_FILE environment variable.
      --messages-path string    An optional file to save the compliance messages emitted by the policy, with one message per line. If not set, messages will be printed.
      --no-colors               Disables colored output. By default, output is printed with colors.
  -p, --policy string           The input Policy or ConfigurationPolicy to execute
      --print-diffs             Set to false to omit any diffs generated by the policy. (default true)
      --status-path string      An optional file to save the full resulting status of the policy. 

I don't think that we need to document every option in both commands, and I've provided a draft below of what I think are the important pieces.

• [ ] *Add Required access level *(example, *Cluster
  Administrator*) for the user to complete the task:

• [ ] Add verification at the end of the task, how does the user
  verify success (a command to run or a result to see?)

• [x] Add link to dev story here: The original epic for the `dryrun` CLI was https://issues.redhat.com/browse/ACM-17272 , but it was only tech preview at that point. I include it here just for reference.

5. - [ ] Mandatory for bugs: What is the diff? Clearly define what the
problem is, what the change is, and link to the current documentation. Only
use this for a documentation bug.

Example Draft Content 

`template-resolver`

The `template-resolver` is a subcommand for `policytools` that resolves managed cluster and hub cluster templates that are embedded in policies. The template-resolver reads an input policy from either a file, or from standard input.

To resolve a policy with hub cluster templates, you must provide the --cluster-name argument with the name of a managed cluster that is imported into {acm-short}, and you must provide the --hub-kubeconfig argument with the path to a kubeconfig file that references the hub cluster.

If the input policy uses the `.ObjectName` or `.ObjectNamespace` template variables, you need to set the values with the `-object-name` and `-object-namespace` arguments.

The `template-resolver` connects to the managed cluster and hub cluster to retrieve information necessary to resolve the templates. You can view the resources it retrieved by providing paths via the `-save-resources` and `-save-hub-resources` arguments. The resulting files can be used as inputs by the `dryrun` subcommand.

`dryrun`

The `dryrun` subcommand for `policytools` executes a given ConfigurationPolicy entirely locally, using static input resources for the cluster state.

To execute a policy, you must provide the path to the ConfigurationPolicy YAML via the `--policy` flag. Any number of additional resource YAML files may be provided to the tool, and will be used as the current cluster state. For example, if your policy defines a specific configuration for a namespace, you should provide the current state of the namespace to see what the policy will do in that situation. Multiple resources can be in the same resource file.

By default, `dryrun` prints the resource diffs for any objects defined in the policy, as well as the compliance messages that the ConfigurationPolicy would emit. To save the compliance messages to a separate file, use the `-messages-path` argument. To save the full policy status, use the `-status-path` argument.

If the policy would be NonCompliant based on the inputs, the tool will return a non-zero exit code. To compare the resulting status against a known status, use the `--desired-status` argument. For example, to verify that the policy would report a missing resource, provide a YAML file with that missing resource inside a `.relatedObjects` list. As another example, to verify that the policy would be NonCompliant, provide a YAML file with `compliant: NonCompliant`.