docs: record the install argument hash in canister history

docs/references/ic-interface-spec/abstract-behavior.md

@@ -424,6 +424,7 @@ ChangeDetails
   | CodeDeployment {
       mode : CodeDeploymentMode;
       module_hash : Blob;
+      args_hash : opt Blob;
     }
   | LoadSnapshot {
       from_canister_id : PrincipalId;
@@ -2504,6 +2505,7 @@ New_canister_history = {
     details = CodeDeployment {
       mode = A.mode;
       module_hash = SHA-256(A.wasm_module);
+      args_hash = opt SHA-256(A.arg);
     };
   };
 }
@@ -2670,6 +2672,7 @@ New_canister_history = {
     details = CodeDeployment {
       mode = Upgrade;
       module_hash = SHA-256(A.wasm_module);
+      args_hash = opt SHA-256(A.arg);
     };
   };
 }

docs/references/ic-interface-spec/changelog.md

@@ -8,6 +8,13 @@ sidebar:
 
 ## Changelog {#changelog}
 
+### 0.71.0 (2026-11-XX) {$0_71_0}
+<!-- Needs human verification: date by the day dfinity/ic#12077 reaches all subnets -->
+* New field `args_hash` of a code deployment in the canister history, holding the SHA-256 hash of the
+  argument `arg` of `install_code` (and `install_chunked_code`) that was passed to the canister's
+  `canister_init` or `canister_post_upgrade` method. The field is `null` for code deployments recorded
+  before the system started recording it.
+
 ### 0.70.0 (2026-10-05) {$0_70_0}
 * New variant `secp256r1` of `ecdsa_curve`, selecting threshold ECDSA on the NIST P-256 curve in
   `ecdsa_public_key` and `sign_with_ecdsa`. Key derivation follows SLIP-10 and signatures are encoded as

docs/references/ic-interface-spec/management-canister.md

@@ -371,7 +371,7 @@ Provides the history of the canister, its current module SHA-256 hash, and its c
 
 The canister history consists of a list of canister changes (canister creation, code uninstallation, code deployment, loading a snapshot, controllers change, canister renaming). Every canister change consists of the system timestamp at which the change was performed, the canister version after performing the change, the change's origin (a user or a canister), and its details. The change origin includes the principal (called *originator* in the following) that initiated the change and, if the originator is a canister, the originator's canister version when the originator initiated the change (if available).
 - Canister creation is described by the full set of controllers along with a [hash of the environment variables](./https-interface.md#hash-of-map), if environment variables were specified. The order of controllers stored in the canister history may vary depending on the implementation.
-- Code deployment is described by its mode (code install, code reinstall, code upgrade) and the SHA-256 hash of the newly deployed canister module.
+- Code deployment is described by its mode (code install, code reinstall, code upgrade), the SHA-256 hash of the newly deployed canister module, and the SHA-256 hash of the argument passed to the canister's `canister_init` or `canister_post_upgrade` method (the field `arg` of `install_code`). The hash of the argument is `null` for code deployments recorded before the system started recording it.
 - Loading a snapshot is described by the canister ID of the canister from which the snapshot was loaded (if that canister ID is different than the canister ID onto which the snapshot is loaded), the snapshot ID, the canister version and timestamp at which the snapshot was taken (the canister version and timestamp refer to the canister from which the snapshot was loaded), and the source of the snapshot (canister state or metadata upload).
 - Controllers change is described by the full new set of controllers after the change. The order of controllers stored in the canister history may vary depending on the implementation.
 - Canister renaming is described by the canister ID and the total number of canister changes before renaming as well as the canister ID, the canister version, and the total number of canister changes of the new canister ID. Because only a dedicated NNS canister can perform canister renaming, the actual principal who requested canister renaming is recorded in a separate field `requested_by`. The total number of canister changes reported by the IC method `canister_info` is overriden to the total number of canister changes of the new canister ID. Canister changes referring to the canister ID before renaming are preserved.

public/references/ic.did

@@ -76,6 +76,7 @@ type change_details = variant {
     code_deployment : record {
         mode : variant { install; reinstall; upgrade };
         module_hash : blob;
+        args_hash : opt blob;
     };
     load_snapshot : record {
         from_canister_id : opt principal;