diff --git a/notes.md b/notes.md
index dfc54b9..77f742e 100644
--- a/notes.md
+++ b/notes.md
@@ -193,3 +193,32 @@ prompt injection in comments, aimed at the reviewer, is an expected attack.
   language-agnostic.
 - **Unknown metadata keys** are preserved verbatim on rewrite (see
   `Metadata#extra`), so optional spec fields survive a tool that predates them.
+- **Snippet-hosting providers.** `Provider::PROVIDERS` covers GitHub Gist and
+  OpenGist; GitLab and Gitea snippets have no provider, so they fall through to
+  `DefaultProvider` and only work if the pasted URL already points at raw
+  content. Gitea matters now that picopackage itself is hosted on one. A Gitea
+  snippet is `https://<host>/snippets/<id>` → `…/snippets/<id>/raw`; GitLab is
+  `https://gitlab.com/(-/)?snippets/<id>` → `…/snippets/<id>/raw`. They sit on
+  opposite sides of the `handles_url?` contract: GitLab is a fixed host, so it
+  can answer `true` by pattern like `GithubGistProvider`, while a self-hosted
+  Gitea can be any domain and has to answer `:maybe` and prove itself by
+  fetching, like `OpenGistProvider`.
+- **`test_method`.** `test_url` is carried in `Metadata`; `test_method` (the
+  name of a test defined inside the payload itself) was in the original spec and
+  never implemented. It only earns its place if `ppkg` can actually run it,
+  which means executing upstream code — so it's blocked behind the signing work
+  above, not just unimplemented.
+- **Is a picopackage necessarily code?** The spec repo answered this and the
+  answer never made it here: “a scheme for sharing text content, often source
+  code… to track a single file of text”, packaging “code or configuration or
+  data”. So the scope is text, not code. Nothing in the tool assumes otherwise,
+  but nothing states it either, and it decides two things downstream: the
+  comment-style table above, and `test_url`/`test_method`, which only mean
+  anything for the code case.
+- **`source_url` is an overloaded name.** The pinning proposal above wants
+  `source_url` for an immutable revision pointer. The spec repo already used
+  that name for something else — there, `url` was the human-readable page and
+  `source_url` the optional direct/raw link “if `url` isn’t parsable”, which is
+  the job `Provider` now does by resolution rather than by metadata. If pinning
+  is implemented under that name, it is a third meaning for the same key; worth
+  picking a fresh one (`pinned_url`, `revision_url`) instead.