docs(agents): record our fork's PR conventions

AGENTS.md

@@ -112,8 +112,9 @@ An empty database is a bad test. Seed your worktree's `.t3` with a copy of real
 ## Pull requests
 
 - Never make a PR unless the developer explicitly asks you to do so.
+- PRs target this fork (`TrogonStack/t3code`), never `pingdotgg/t3code`, unless the developer asks for the change to go upstream.
 - Conventional commit titles, plain language: `fix(web): new threads no longer spike CPU`.
-- Body: the problem in a sentence or two, then how you fixed it. End with the model and harness that did the work.
+- Body: the problem in a sentence or two, then how you fixed it.
 - UI changes need before/after images. Motion or timing needs a short video.
 - One concern per PR. If the description says "also", split it.
 - When babysitting: poll checks and comments newer than the last push, verify each bot finding against the source, fix real ones, dismiss false positives with a written reason. Stay quiet when nothing is new. Stop when the bots are green on the latest commit.

docs/fork/0010-fork-pull-request-conventions.md

@@ -0,0 +1,31 @@
+# 0010: Pull request conventions of our own
+
+- PR: [TrogonStack/t3code#19](https://github.com/TrogonStack/t3code/pull/19)
+- Status: active
+
+## What you can do now
+
+- Ask for a PR and get one on this fork. Upstream is only the target when you
+  say so, so no branch reaches the upstream project by accident.
+- Get a PR body that describes the change and nothing else. Whether to say
+  what produced it is yours to decide per PR, not a standing convention.
+
+## Why
+
+Upstream's contributing guidance is written for people contributing to
+upstream, where the fork is not a concept and its own repository is the
+obvious base. Read literally here, it points every PR at a project that is not
+ours. That one is worth writing down rather than leaving to inference, because
+it is a one way door: opening a PR against upstream publishes the branch
+there, and closing it afterwards does not take it back.
+
+The authorship footer is the ordinary case of a convention that should not be
+inherited without asking. Attribution is a call for whoever owns the
+repository.
+
+## Upstream considerations
+
+Fork local by definition. Upstream should keep the conventions it has, and
+neither change is something to submit. Both edit the shared instructions file,
+which is exactly the kind of edit a sync quietly reverts, so a rebase has to
+carry them forward deliberately.

docs/fork/README.md

@@ -33,4 +33,5 @@ Each entry uses these sections:
 | 0006 | [Fork schema on its own migration ledger](./0006-fork-migration-ledger.md)                     | [#13](https://github.com/TrogonStack/t3code/pull/13), [#16](https://github.com/TrogonStack/t3code/pull/16) | active |
 | 0007 | [API-key Codex installs are not reported as broken](./0007-codex-api-key-auth-is-supported.md) | [#15](https://github.com/TrogonStack/t3code/pull/15)                                                       | active |
 | 0008 | [Drop a folder on the sidebar to add a project](./0008-drop-a-folder-to-add-a-project.md)      | [#17](https://github.com/TrogonStack/t3code/pull/17)                                                       | active |
+| 0010 | [Pull request conventions of our own](./0010-fork-pull-request-conventions.md)                 | [#19](https://github.com/TrogonStack/t3code/pull/19)                                                       | active |
 | 0011 | [Follow the background work a thread left running](./0011-follow-background-work.md)           | [#20](https://github.com/TrogonStack/t3code/pull/20)                                                       | active |