docs: put the project's working rules in the wiki

Principles, collection rules and the inverted model in architecture.md, research and citation rules in profiling.md, platform and scraper rules in their pages, tool conventions in tools.md, test and commit expectations in testing-guide.md, installer constraints in installer.md. Each rule sits where a reader looks for it, with its reason. Also fixes the stale release-job line, the suite command without -t ., and the unsourceable definition.

wiki/adding-a-platform.md

@@ -328,6 +328,13 @@ If a file already exists at the output path, the CLI preserves fields that the
 scraper does not generate (e.g. `data_directories`, manually added metadata).
 Only the `systems` section is replaced.
 
+The YAML is the scraper's output and is never edited by hand: the next scrape
+would undo the edit, and the file would stop describing the platform. Anything
+an export has to write back (the platform's own system id, path, name) is
+recorded by the scraper and never reconstructed later, because several of the
+platform's systems can fold into one of ours. A rescrape can add systems, so
+read `verify.py --platform` before committing the regenerated YAML.
+
 Verify the result:
 
 ```bash
@@ -451,6 +458,10 @@ For platforms that only run on one target (e.g. RetroBat on Windows, RomM in the
 browser), create a static YAML file in `platforms/targets/` instead of a scraper.
 Set `target_scraper: null` in the registry.
 
+Its target writes `cores: null`, which means every core the platform declares.
+A core list written by hand there falls behind the scraped platform and drops
+cores the pack ships.
+
 ## Step 7: Add install detection (optional)
 
 The `install` section in `_registry.yml` tells `install.py` how to detect