Update docs

Author: phpfui

docs/5. Virtual Fields.md

@@ -3,7 +3,7 @@
 
 You can define virtual fields with get and set semantics for any **\App\Record** class. Virtual fields are evaluated before any database field, so you can override the database defaults if needed, or create new functionality.
 
-Every **\App\Record** class has a static $virtualFields array defined. The key of the array is the name of the virtual key.  The value for each virtual field is an array of strings. The first string is the virtual field class name. Subsequent parameters are are passed to the **getValue** and **setValue** methods.
+Every **\App\Record** class has a static $virtualFields array defined. The key of the array is the name of the virtual field.  The value for each virtual field is an array of strings. The first string is the virtual field class name. Subsequent parameters are are passed to the **getValue** and **setValue** methods.
 
 Note that virtual fields are created each time they are accessed and not stored or cached in the [\PHPFUI\ORM\Record](http://phpfui.com/?n=PHPFUI%5CORM&c=Record) object.  This means you can not change the virtual field on the **Record** object itself. You can only assign it to the Record object, which will store the value represented by the virtual field in the object, but not the virtual field itself.
 

docs/6. Migrations.md

@@ -24,7 +24,7 @@ else
 You can include this logic in your deployment for full control of when migrations happen.  The **migrateTo()** method will run the migrations in the correct order (up or down).  You can also run migrations individually.
 
 ## Migration Architecture
-Migrations are located in the **\App\Migration** namespace.  They must be a class named Migration_**X** where **X** is an integer number. Migrations are run by migration number and not date to avoid sync conflicts on release that plague more common migration systems. Conflicts with migrations due to branching are handled by git at merge time.
+Migrations are located in the **\App\Migration** namespace.  They must be a class named Migration_**X** where **X** is an integer number. Migrations must start with 1 and be contigious integers without gaps to the last migration. Gaps in the sequence are not allowed. Migrations are run by migration number and not date to avoid sync conflicts on release that plague more common migration systems. Conflicts with migrations due to branching are handled by git at merge time.
 
 Typical migration:
 ```php