ara3d-sdk AGENTS.md

AGENTS.md — Working in the Ara3D SDK

This is the operating guide for AI agents (and humans) writing code in this repository. Read it before making changes. It encodes how this codebase is built and maintained.

This project is maintained by one person with virtually no outside contributions. Optimize for that reality: code that is simple, correct, easy to refactor, and cheap to understand six months later beats code that is clever, abstract, or "enterprise-grade".

---

1. The two rules that override everything

1. The code must work. Correctness first. A working simple version beats a broken elegant one.
2. The code must be easy to improve and refactor. Everything below serves this.

If a guideline here ever conflicts with these two rules, the two rules win.

---

2. The standard workflow (do things in steps)

Work in small, verifiable increments. Never combine "make it work" with "make it pretty" in the same step.

1. Add code + tests for the smallest useful slice of behavior.
2. Verify it works — build and run the tests (see §8). Do not proceed on a red build.
3. Plan the refactor — note what should improve. Add // TODO: markers in code and a matching entry in docs/TECHNICAL_DEBT.md.
4. Save the state — this is a natural stopping/commit point. The working version is preserved.
5. Apply the refactor — change structure, not behavior. Tests from step 1 prove you didn't break anything.

Never refactor on a red build. If tests are failing, get them green first, then refactor.

When given a multi-step task, use a todo list and keep it current.

---

3. Core principles

First, the monorepo-wide API-first design principles (canonical list in the root AGENTS.md) apply to everything here:

• Write code as if writing a public API — these SDK libraries literally are one.
• Eat your own dogfood: consume existing SDK APIs before adding new ones; awkwardness in an existing API is a reason to improve it, not bypass it.
• Design for relocation: code should move cleanly between projects/layers — few, explicit dependencies.
• Write for the next learner: someone else must be able to learn and use it quickly.
• Obvious usage: correct use discoverable from signatures and names alone.
• Types and affordances guide correct use: illegal states unrepresentable; misuse a compile error where possible.
• Path of least resistance = best practice: the easiest way must be the right way.
• Composition and reuse by default: every new piece is a candidate building block.