The existing analysis is actually sufficient. Document why this is.

HISTORY.md

@@ -6,6 +6,8 @@ History of SixtyPical
 
 *   `or a, z`, `and a, z`, and `eor a, z` compile to zero-page operations
     if the address of z < 256.
+*   More thorough tests and justifications written for the case of
+    assigning a routine to a vector with a "wider" type.
 
 0.15
 ----

README.md

@@ -77,7 +77,6 @@ are trashed inside the block.
 ### And at some point...
 
 *   `low` and `high` address operators - to turn `word` type into `byte`.
-*   Tests, and implementation, ensuring a routine can be assigned to a vector of "wider" type
 *   Related: can we simply view a (small) part of a buffer as a byte table?  If not, why not?
 *   Related: add constant to buffer to get new buffer.  (Or to table, but... well, maybe.)
 *   Check that the buffer being read or written to through pointer, appears in appropriate inputs or outputs set.

tests/SixtyPical Analysis.md

@@ -2309,7 +2309,10 @@ If the vector fails to take an input that the routine takes, that's an error.
     | }
     ? IncompatibleConstraintsError
 
-If the vector produces an output that the routine doesn't produce, that's an error.
+If the vector produces an output that the routine doesn't produce, that's not an error.
+(The interface claims the result of calling the routine is defined, but the implementation
+actually preserves it instead of changing it; the caller can still treat it as a defined
+output.)
 
     | vector routine
     |   inputs x, y
@@ -2332,7 +2335,7 @@ If the vector produces an output that the routine doesn't produce, that's an err
     | {
     |     copy foo, vec
     | }
-    ? IncompatibleConstraintsError
+    = ok
 
 If the vector fails to produce an output that the routine produces, that's an error.