Document project architecture and asset provenance

CONTRIBUTING.md

@@ -0,0 +1,48 @@
+# Contributing
+
+NETfishing is currently developed through focused changes on the repository's
+active development branch. Coordinate scope with the project owner before
+starting substantial work.
+
+## Change discipline
+
+- Keep a change focused; avoid unrelated cleanup.
+- Inspect the working tree before editing and preserve existing work.
+- Do not change protocol, save, settings, identity, or portable-data versions
+  as release-label housekeeping.
+- Treat the host as authoritative for catches, purchases, sales, jobs, mail,
+  and other shared state.
+- Keep presentation-only systems out of save files and network messages.
+- Store runtime assets under repository-owned paths; never reference a
+  workstation sync or temporary directory.
+- Record the source and license of newly imported assets.
+- Do not commit `.godot/`, test data, logs, captures, or build outputs.
+
+## Before requesting review
+
+```sh
+git diff --check
+scripts/run_validations.sh quick
+git status --short
+```
+
+Choose additional focused tests from [`docs/TESTING.md`](docs/TESTING.md).
+Changes involving networking should run the network suite and a real
+two-process check. Visual changes still require graphical review; headless
+tests are supporting evidence, not a replacement.
+
+## Commits
+
+- Stage audited paths explicitly.
+- Use a concise imperative subject that describes the outcome.
+- Do not mix generated build artifacts with source changes.
+- Do not rewrite published release tags.
+- Describe behavior, compatibility impact, validation, and asset provenance in
+  the review or release record.
+
+## Style
+
+Follow the conventions already present in the surrounding GDScript, scene, and
+resource files. Prefer typed values, named constants, shared resources, and
+small domain-specific services. Avoid duplicating protocol definitions or
+using display strings as persistent identifiers.