Replace the inherited AI ban in AGENTS.md with instructions for this fork

[matasarei]

Hi Sean,

First, a personal word. I think this fork should find its own way, and I fully support the initiative and the motivation behind it. Getting Haiku to the desktop on real G3 and G4 hardware, with sound, WiFi and native modesetting, is remarkable work, and I would like to help it stay healthy as it grows. Issues are disabled on the repository, so this comes as a pull request rather than a proposal. Take whatever is useful and drop the rest.

Why

AGENTS.md at the repository root is still upstream Haiku's file. Its only content is "No AI-generated code", so every coding agent that opens this tree is told to refuse the kind of work this whole branch was made with, and gets no guidance about the project itself: the two build trees, the -mcpu=750 pin on the kernel and loader, the byte-order and MMIO-ordering rules the port has already learned the hard way, or how to test before spending an image build.

What this adds

A short AGENTS.md written for this fork, plus a one-line CLAUDE.md containing @AGENTS.md. Claude Code reads CLAUDE.md, not AGENTS.md, so without that import the file is skipped by the tool used for most commits here.

Sections:

• Ground rules: a human is accountable; agents never push, merge or open PRs unasked; agent work is disclosed with the Co-Authored-By trailer already in use; commit messages say what was verified where; no invented hardware behaviour; MIT license and provenance for ported code and firmware. Modelled on the Linux kernel's coding-assistants.rst, LLVM's AI tool policy and Fedora's AI-assisted contribution policy.
• Scope: PowerPC only: non-PPC architecture code is to be removed rather than maintained, with the candidate paths, what must stay (generic and host-side code, since the build host is x86_64/arm64), and a one-subsystem-per-commit method. Upstream fixes come in by cherry-pick; the branch is 174 ahead and 274 behind haiku/master, so merging is not realistic anyway.
• Build: generated.ppc / generated.ppc-g4, HAIKU_PPC_CPU/_TUNE/_NOVEC, the kernel and loader pin, -Werror being off for ppc, single targets, where image contents and the version live.
• Test before you build an image: compile in both trees, host-side tests via BuildPlatformTest, CppUnit tests, emulator boot with the serial-log check, then named hardware. New code and its tests land in the same commit; a definition of done.
• PowerPC correctness: distilled from your commit history (endianness, eieio/sync, AltiVec, FCode ROMs vs BIOS, no serial port, no battery).
• Style and commits: Haiku coding guidelines, checkstyle.py, the area: what subject convention.
• Where the PowerPC code lives.

The file is deliberately kept short. Anything that needs more room (for example a step-by-step procedure for removing a non-PPC subsystem) belongs in a skill or a doc under docs/develop/, not in AGENTS.md.

What was checked

Every path, target name, variable and flag in the file was checked against the tree (ArchitectureRules, DefaultBuildProfiles, TestsRules, configure, the Jamfiles, the commit messages). No code is changed and nothing was built as part of this PR.

One thing left for you

The exact dingusppc command line and machine config are not recorded anywhere in the repository. There is an HTML comment placeholder in the "Emulator boot" step; pasting yours there makes the boot check reproducible for anyone.

Skills are recommended

AGENTS.md is kept short on purpose. Procedures that need more room belong in skills (.claude/skills/<name>/SKILL.md, or the equivalent for other agent tools), which load only when the task calls for them. Write your own for the things only this project knows, and pick up a few existing ones for the general discipline. Not too many; each one is more context to read.

Worth writing for Tabby:

• remove-arch: the checklist for dropping one non-PPC subsystem (grep the path and macros, fix every SubInclude, build both trees, record removed paths in the commit).
• boot-test: the dingusppc command line, how to capture the serial log, and the pass/fail check. This is the one piece of knowledge that exists only on your machine today.
• hardware-report: what to record when something is tried on real hardware (model identifier, device IDs, what worked, what did not), so it lands in the commit message in the same shape every time.

Existing ones that fit, from obra/superpowers:

• test-driven-development: the test in the same commit as the code, which is what the "test before you build an image" section asks for.
• systematic-debugging: find the cause before changing anything. Most of this port's hardest fixes (the -mtune reorder, the PLL index barrier, the FIFO timing) were exactly that kind of work.
• verification-before-completion: no "done" without evidence, which matches the ground rule about stating what was verified.

For writing your own, anthropics/skills ships a skill-creator that walks through the format.

Noticed along the way, not changed here

• build/jam/images/definitions/minimum copies NetSurf from the absolute host path /work/netsurf-build/nspkg/apps, so an image build on another machine depends on that directory existing. The file recommends guarding such steps.
• -Werror is disabled for ppc, so new warnings go unnoticed unless someone reads the log.
• A checkout on a case-insensitive filesystem (default macOS) collides on two upstream file pairs (Screenshot/screenshot catalogs, CollatorTest.cpp/collatorTest.cpp). ReadMe.Compiling.md already requires a case-sensitive filesystem, so this is only a note for contributors.