doc: align with new upgrade.go refactoring

MAINTAINERS.md

@@ -46,7 +46,7 @@ The Release Owner and other appropriate stakeholders must agree on:
 
 - [ ] When a new release is planned, create a new branch from branch `release-mainnet1B` with a name like `dev-$releaseShortLabel` (example: `dev-upgrade-8`). This can be done from the command line or the [GitHub Branches UI](https://github.com/Agoric/agoric-sdk/branches).
 - [ ] Initialize the new branch for the planned upgrade:
-  - [ ] In **golang/cosmos/app/app.go**, update the `upgradeName` constants and the associated upgrade handler function name to correspond with the [_**upgrade name**_](#assign-release-parameters).
+  - [ ] In **golang/cosmos/app/upgrade.go**, update the `upgradeName` constants and the associated upgrade handler function name to correspond with the [_**upgrade name**_](#assign-release-parameters).
     Remove from the function any logic specific to the previous upgrade (e.g., core proposals).
   - [ ] Ensure that **a3p-integration/package.json** has an object-valued `agoricSyntheticChain` property with `fromTag` set to the [agoric-3-proposals Docker images](https://github.com/Agoric/agoric-3-proposals/pkgs/container/agoric-3-proposals) tag associated with the previous release
     (example: `use-upgrade-7`).

a3p-integration/README.md

@@ -66,7 +66,7 @@ For a chain software upgrade proposal, the `type` is `"Software Upgrade Proposal
    particular, it can have a `coreProposals` field which instructs the chain
    software to run other core proposals in addition to the one configured in the
    chain software's upgrade handler (see `CoreProposalSteps` in
-   `/golang/cosmos/app/app.go`).
+   `/golang/cosmos/app/upgrade.go`).
   - See **Generating core-eval submissions** below for details.
 
 For an (evolving) example, see `a:upgrade-next` in master.

a3p-integration/proposals/e:upgrade-next/README.md

@@ -1,11 +1,14 @@
 # Proposal to upgrade the chain software
 
-The `UNRELEASED_A3P_INTEGRATION` software upgrade may include core proposals defined in
-its upgrade handler. See `CoreProposalSteps` in the `unreleasedUpgradeHandler`
-in [golang/cosmos/app/app.go](../../../golang/cosmos/app/app.go).
+The `UNRELEASED_A3P_INTEGRATION` software upgrade may include core proposals
+defined in its upgrade handler. See `CoreProposalSteps` in the
+`unreleasedUpgradeHandler` in
+[golang/cosmos/app/upgrade.go](../../../golang/cosmos/app/upgrade.go).
 
 This test proposal may also include `coreProposals` in its `upgradeInfo`, which
 are executed after those defined in that upgrade handler. See `agoricProposal`
 in [package.json](./package.json).
 
-The "binaries" property of `upgradeInfo` is now required since Cosmos SDK 0.46, however it cannot be computed for an unreleased upgrade. To disable the check, `releaseNotes` is set to `false`.
+The "binaries" property of `upgradeInfo` is now required since Cosmos SDK 0.46,
+however it cannot be computed for an unreleased upgrade. To disable the check,
+`releaseNotes` is set to `false`.

packages/deploy-script-support/README.md

@@ -70,8 +70,7 @@ objects.
 
 The script describes how to build the core proposal. For
 `agoric-3-proposals` and uploading to the chain, the script must be named in the
-`CoreProposalSteps` section in
-[`app.go`](https://github.com/Agoric/agoric-sdk/blob/b13743a2cccf0cb63a412b54384435596d4e81ea/golang/cosmos/app/app.go#L881),
+`CoreProposalSteps` section in [`upgrade.go`](../../golang/cosmos/app/upgrade.go),
 and its `defaultProposalBuilder` will be invoked directly.
 
 Script files should export `defaultProposalBuilder` and a `default` function