Update contributing guide

CONTRIBUTING.md

@@ -1,7 +1,7 @@
 Contributing to Feder
 =====================
 
-Thank you for your interest in contributing to feder. This document outlines
+Thank you for your interest in contributing to Feder. This document outlines
 the development workflow and the tools we use to maintain code quality.
 
 Please also read the project's [AI usage policy](./AI_POLICY.md) before
@@ -31,6 +31,9 @@ Development workflow
 We use mise tasks to automate common development steps. Please ensure your
 changes pass the automated checks before submitting a pull request.
 
+Please open pull requests against the `main` branch of the Feder upstream
+repository.
+
 ### Code formatting
 
 We use `rustfmt` to maintain a consistent coding style. You can automatically
@@ -54,6 +57,39 @@ We configure Clippy to treat all warnings as errors in `Cargo.toml`. This
 ensures that the codebase remains clean and free of common pitfalls. If
 `mise run check` fails, please address the reported issues before proceeding.
 
+
+Project direction
+-----------------
+
+Feder is still early-stage, so APIs and crate boundaries may change. The
+current direction is to build Feder as a Rust framework for ActivityPub
+applications with a portable protocol core and platform-specific runtimes.
+
+The main architectural rule is:
+
+> The core decides what should happen. The runtime decides how it happens on a
+> specific platform.
+
+In practice, this means protocol decisions should stay separate from platform
+execution. The intended crate roles are:
+
+ -  `feder-vocab`: Type-safe representations of Activity Vocabulary objects,
+    such as actors, notes, and activities.
+ -  `feder-core`: The portable ActivityPub protocol engine, responsible for
+    protocol decisions and state transitions.
+ -  Runtime crates: Platform-specific execution layers for networking, storage,
+    clocks, timers, async runtimes, and operating system or hardware
+    integration.
+
+When contributing to `feder-core`, avoid adding direct dependencies on HTTP
+clients or servers, databases, filesystems, async runtimes, system clocks, or
+platform-specific crates. Runtime crates may use those dependencies when
+appropriate, but those choices should not leak into the portable core.
+
+Core behaviour should generally be tested by feeding an input into the core and
+asserting the returned actions. Core tests should not require real networking,
+storage, or async execution.
+
 ### Git pre-commit hook
 
 You can automate the quality checks by registering a Git pre-commit hook. This