[dpadr]

What and why

This is a proposal. Everything here is for the maintainers to accept, change or reject.

Most of nxnative is now written by agents, started by many people who don't see each other's sessions, and an agent knows only what it reads. That makes work cheap to start and easy to multiply, and the open pull requests show the result: Ocarina of Time, Star Fox, Donkey Kong Bananza and Mario Kart World each have several people on them at once; work gets done twice or undone (HDR output in two pull requests, #1176 and #1249; Game Mode turned on and off for every Mac app on the same day); and measurements often don't say which device they were made on.

None of that is anyone's fault: nothing tells an agent what the project is for, what already exists, or what a change must not break. This pull request writes that down where agents read it, and builds on the tools the repository already has (regress.py, the area and game labels, the triage report) instead of adding new machinery.

A charter (docs/charter.md), for agent sessions, which opens with five lines for anyone who reads nothing else: start from the latest main and look for existing work first; make your own work findable; correctness first, and no regressions; name the device; the bar rises with reach. In full:

• What it does not ask: no one needs a base Mac, owes a test on one, or has to work on low-spec performance. Bringing up games on any Mac, and features that use a fast Mac's headroom, are welcome. It asks that a measurement names its device, and that a cost known on other devices is written down.
• Aim: games play as they do on the console (picture, pacing, real time, the console's controllers, gameplay speed), and better than the console where a device has the headroom.
• Priorities: correctness, then no regressions, then performance on every device. A change that makes a game more correct wins even when it is slower; it states the cost.
• What a regression is: something that worked and now breaks, or something that got slower or bigger for nothing in return. A cost that buys correctness or a feature is stated, not a regression.
• Reference devices: an 8 GB M1 (Switch games) and a 16 GB M2 with a 10-core GPU (Switch 2 games) are where low-spec work aims and testers report, not a bar every game or change must clear; some games will need more. The iPhone and iPad get their own note: iOS ends an app past its memory limit, and the same host and translator run there, so a shared change's memory or CPU cost reaches them. Steam survey figures for the Macs people play on are in an appendix.
• Process: fetch the latest main and look for existing work before starting or filing an issue, and make your own work findable; the bar a pull request must clear rises with its reach and risk (narrow, shared, wide, read mostly from its labels); a default every game gets needs evidence beyond one device, a switch and an entry in a decisions log.
• Contributions wanted: optimization and shared fixes as well as game support, and testing on low-spec devices, which needs no code. A test request never holds a pull request.

Where agents and contributors meet it:

• AGENTS.md: read the charter first; fetch the latest main and check for existing work (by label and by title) and make yours findable; never work on your local main; ask before long builds or deleting; measure on the device a claim is about. The shader-chain procedure and per-build rules moved to 06-dev-loop.md to make room (unchanged).
• docs/agents/06-dev-loop.md: how to find existing work (with gh and on the web), the branch cycle, and a guide to judging a pull request's tier.
• CONTRIBUTING.md, docs/agents/README.md, the pull request template: the same rules where people read them.
• A Test request on a low-spec device issue form, labelled automatically (issue_areas.py, pr_areas.py, with tests).
• docs/decisions.md: a log of choices every game gets, starting with the Game Mode opt-out as it stands.

Revised after review: crghofficial's review reshaped the priorities, the definition of a regression and the device targets: correctness wins over speed, a slowdown that buys correctness is a stated cost rather than a regression, and the base Macs are reference points rather than targets. He is credited as co-author on that commit.

Checked

• Tests: dm/tools/tests/test_docs.py (links, anchors, AGENTS.md under its 1,500 words), test_issue_areas.py, test_pr_areas.py.
• Docs and labelling only: no host, chain or game code changes, so no regress.py run.
• Not checked: the new issue form on GitHub itself (its YAML is not parsed locally).

Docs

• No game files, keys or data extracted from a game

🤖 Generated with Claude Code, reviewed and edited by @dpadr

[crghofficial]

EDIT: dpadr has since heavily edited their original PR. This comment now looks like an extreme overreaction without that context. I recommend looking at their original PR before reading my comment.

It is absurd for you to think that your goals are everyone else's goals. I don't give two shits about 16gb MacBook Airs, let alone 8gb models. I contribute to NXNative through other accounts and will continue to utterly disregard this 'charter' and work on what I want to work on, which is getting new games up and running on high-spec Macs.

Fuck yourself.

[crghofficial]

What it does not ask: no one needs a base Mac or has to work on low-spec performance; bringing up games on any Mac, and features that use a fast Mac's headroom, are welcome. It asks that shared code does not get worse on the base Macs, and that a measurement names the Mac it was made on.

Less offensive than your original draft, but you're still demanding additional work be done by those actually contributing (people who are not you) to simulate low-spec hardware because you don't want to upgrade, which doesn't seem like a fair exchange.

Your targets for shared code are - frankly - ridiculous and unrealistic. Expecting OOT to run well on a 16gb device - not a consequence of actual developers doing work as part of bring up, but as additional work to benefit devices they do not own - represents extreme entitlement. Who the fuck are you - someone without meaningful contributions to the project - to say what the project goals are? Where the fuck do you get off demanding, and I quote from you:

Goals: every Switch game playable on an 8 GB M1 (benchmark: Tears of the Kingdom), every Switch 2 game on a 16 GB M2 with a 10-core GPU (benchmark: Ocarina of Time, once it plays).

No.

Additionally, It is unreasonable to expect that '..shared code does not get worse on the base Macs'. Shared code is introduced with support for new games. Some pre-existing shared code must be modified to achieve correctness. That can and will cause performance consequences for low end devices. What you need to do is find a way to accept that. Correctness is far more important than incorrect behavior that has a performance benefit for low end devices.

Priorities, the order a conflict is decided in: correctness, then no regressions, then performance on the lowest devices. Faster Macs can do more behind settings, but a gain on one class of Mac paid for by another is a regression.

No. These are not my priorities. My priorities are correctness followed by a better experience than the actual Nintendo hardware delivers. I do not care about performance on the lowest end devices and do not want changes to benefit low end MacBook Airs messing with anything I contribute that is targeted at devices that have enough ram to offer acceptable experiences with demanding titles.

'No regressions' is being used in an incorrect way by a non-developer; what dpadr means is 'performance on my low end Mac doesn't get worse', even if the change is one that matches how Ampere works. At the end of the day, it's going to be challenging to get some of the heavier games to work on low end devices. Star Fox leans on DLSS fairly heavily and runs a neural network for the camera feature. That game is going to be more demanding that Splatoon Raiders. The solution to what ails dpadr is on Apple.com.

Anyway, If someone can improve performance without introducing issues, they can feel free. Introducing a 'charter' designed to benefit owners of the cheapest Macs Apple sells at the expense of the actual people doing the work to bring up titles is offensive.

Again, this is by far the most offensive PR I've read for any project in at least a month. Do better. Take your PR and shove it up your fucking ass. Fuck you.

[crghofficial]

This is less offensive than it was earlier. I still think the proposal is bad/dumb, but it's now not a meaningful blocker for work. I can more or less ignore it now. I won't be making test requests for low end devices - I really did mean it when I stated - multiple times! - that I do not care how demanding titles run on low end devices - but I am happy to explain why a correctness change was made. I am not interested in altering my workflow to benefit devices that I do not own and do not care about.