amadan
Merge branch 'no-github-issues' into main
1 file changed,
+40
−0
AGENTS.md+40 −0
CI passed — run details
diff --git a/AGENTS.md b/AGENTS.md| index aed29f7bf..3447c3be1 100644 |
| --- a/AGENTS.md |
| +++ b/AGENTS.md |
| @@ -83,6 +83,46 @@ incident to clean up rather than a merge that simply doesn't happen. The |
| PR is the one place the branch's diff is read as a single piece rather |
| than commit by commit, while the change can still be turned away. |
| +## Work is tracked on amadan, not GitHub (Paul's rule, 2026-09-05) |
| + |
| +**Do not open issues on github.com/carlosframework/platform.** Not for a |
| +bug you hit, not for a follow-up you noticed while doing something else, |
| +not for a "just so it's written down somewhere" note. That tracker is |
| +closed for new work. |
| + |
| +Everything goes on amadan instead, as a discussion on `carlos/platform`: |
| + |
| + amadan discuss new carlos/platform -title "..." -body - |
| + amadan discuss list carlos/platform # what's already there |
| + amadan discuss show carlos/platform <id> |
| + amadan discuss reply carlos/platform <id> -body - |
| + |
| +Give it a type — `Issue`, `Feature Request` or `Idea` — with |
| +`amadan discuss type`, or leave it untyped and let a person label it. |
| +`amadan discuss types` lists what this repo uses. |
| + |
| +The reason is that a tracker nobody reads is worse than no tracker. CI |
| +moved here on 2026-08-24 and `main` lands here through `amadan branch |
| +merge`; GitHub issues were the last thing left pointing somewhere the |
| +daily loop had stopped looking. 110 open ones had accumulated by |
| +2026-09-05, and triaging every one against `main` found 20 already |
| +fixed — several of them by work that cited the issue number in its own |
| +comments and still never closed it — plus one duplicate. The remaining |
| +89 were migrated to discussions that day, each carrying its full |
| +original text, and all 110 were closed on GitHub with a comment saying |
| +where it went and why. |
| + |
| +That ratio is the argument. Roughly one issue in six was answered |
| +without anyone noticing, which is what a tracker looks like when it has |
| +stopped being part of the loop. |
| + |
| +Reading the old ones is still fine and often useful — code comments cite |
| +them by number constantly (`issue #195`, `(#152)`), and those citations |
| +are historical references, not an invitation to reopen anything. When a |
| +comment cites a GitHub issue that is still real outstanding work, it now |
| +has a discussion too; cite that alongside it rather than renumbering |
| +anything. |
| + |
| ## Build & test |
| - `go build ./...`, `go vet ./...`, `go test ./... -count=1` — all clean, |