Revise descriptions of Arvo arms in ca03.md

content/build-on-urbit/core-academy/ca03.md

@@ -111,10 +111,10 @@ If you read up on the runtime, at some point it used to refer to an “Arvo-shap
 
 Arvo defines four standard arms for vanes and the binary runtime to use:
 
-- `+load` is used in kernel upgrades, allowing Arvo to update itself in-place, canonically at `+4`. (Formerly a `+come` arm was defined to assist in this procedure, targeting `$type` changes.)
-- `+wish` accepts a core and parses it against `%zuse`, which is instrumentation for runtime access, canonically at `+10`. (See `ca02`.)
-- `+peek` grants read-only access to a vane; this is called a _scry_, canonically at `+22`.
-- `+poke` accepts `$move`s and processes them; this is the only arm that actually alters Arvo’s state, canonically at `+23`.
+- `+load` is used in kernel upgrades, allowing Arvo to update itself in-place, and is canonically at `+4`. (Formerly a `+come` arm was defined to assist in this procedure, targeting `$type` changes.)
+- `+wish` accepts a core and parses it against `%zuse`, which is instrumentation for runtime access, and is canonically at `+10`. (See `ca02`.)
+- `+peek` grants read-only access to a vane; this is called a _scry_, and is canonically at `+22`.
+- `+poke` accepts `$move`s and processes them; this arm alters Arvo’s state, and is canonically at `+23`.
 
 Each arm possesses the same structure, which means that as the Urbit OS kernel grows and changes the main event dispatcher can remain the same. For instance, when the build vane `%ford` was incorporated into `%clay`, no brain surgery was needed on Arvo to make this possible and legible. Only the affected vanes (and any calls to `%ford`) needed to change.