Build for myCroquet

myCroquet is the member app for Croquet Queensland. Members sign in at my.croquetqld.org. If you can build for the web, you can now build a feature for it. If you know someone in your club who builds websites, they can build one too.

A public standard

The rules for building a module are written down in a public standard. It is version 1.0, published 4 September 2026. It is self-contained. You do not need access to the myCroquet codebase to follow it.

The kit repository

The standard and everything that goes with it sit in a public repository on GitHub:

https://github.com/automatebrisbaneai/mycroquet-module-kit

The repository holds four things. STANDARD.md is the whole standard. example/mycroquet-module-club-notices/ is a complete worked module, as real files. template/mycroquet-module-YOUR-ID/ is a blank skeleton. submissions/ is where a finished package goes, by a pull request.

The example files are pulled out of the standard by a build script, so the two cannot drift apart.

The technical stack

myCroquet is built with Next.js 16 and the App Router, React 19, TypeScript, Tailwind CSS 4, a shared component kit, and PocketBase as the database.

There is one way to sign in. A member types their email address and receives a code. There are no passwords, and there is no separate administrator login.

What a module is

A module is one manifest file plus the pages and API routes it owns. From that one manifest, the platform works out the menu entry, the page guard and the API guard. There is no other step to register it.

There are about thirty modules today, and almost all of them shipped dark. Dark means the manifest says enabled: false. A dark module does not show in the menu, its pages redirect, and its API routes return 404. Switching it on is a one-line change.

Capability tags

Access is by capability tag, not by role. A role grants a set of tags, and a person can also hold extra tags given one at a time. Every gate checks tags.

The three gates

Every authenticated API route opens with the same three gates, always in this order. First the module gate, then authenticate, then authorise.

A module lives inside myCroquet

A module is part of myCroquet itself. We do not embed outside products in a frame, and we do not open the login to outside sites.

Where to start

Start with the template and the worked example. There is no scaffold or generator command. You copy from the example and fill in the template.

The worked example has been tested in the real app. Its code was placed into the real myCroquet staging checkout and type-checked with npx tsc --noEmit. There were no errors in the example files. That check also found one earlier error, a missing label prop on the text area component, which was fixed in the standard.

The example's unit test was run in the real app with npx vitest run src/lib/club-notices.test.ts. One test file passed, with 3 tests passed, in 641 ms.

Building with an AI

Section 8 of the standard holds a prompt. It is written to be pasted into an AI together with the rest of the document.

We tested it. A fresh AI agent was given only the standard, with no access to the codebase and no way to search it, and asked to follow the section 8 prompt. It produced a complete package that met the standard. Its API routes used the three gates in the right order. It also reported seven points where the standard was unclear or silent. All seven were fixed before publication: nav order numbers, update and delete routes, time zone, the select field shape, component prop contracts, the database client's method surface, and which collections already exist.

What you hand over

You hand over one folder named mycroquet-module-<id>/. It contains:

1. MODULE.md, with eleven questions answered.
2. CHECKLIST.md, ticked, with a line of evidence under each tick.
3. collections.json, listing any database tables needed.
4. A src/ tree that mirrors ours.
5. tests/.

Nothing goes outside those paths. You do not edit any shared file. Registration and any new capability tag are done on our side.

Evidence, not assertion

The checklist asks for a line of evidence under each tick. "Tested" is not evidence. "Ran npx vitest run src/lib/club-notices.test.ts, 3 passed" is evidence. Say what you ran and what happened.

Sending a package

Fork the repository, put your folder under submissions/, and open a pull request. Send one module per pull request. We read it, comment on it, and either accept it or tell you plainly what needs to change.

Nothing you send touches the live app. Your folder lands in the kit repository. If we accept it, we copy it into myCroquet ourselves.

What happens after a package arrives

On our side, the intake runs in this order:

1. Read MODULE.md and CHECKLIST.md.
2. Reject if any file sits outside the package layout or enabled is not false.
3. Check the id and tag are free.
4. Copy the files in.
5. Make three registration edits.
6. Create any database tables.
7. Set environment variables on staging.
8. Run the type check, the unit tests, the staging deploy and the gate-matrix script.
9. Run the submitter's own browser test.
10. Walk it through with the person who decides.
11. Promote to live, still dark.

One person on our side decides whether a module ships and who gets it. Switching a module on is a separate, later decision. Capability tags are granted one person at a time.

If the standard falls short

If your AI asks a question the standard does not answer, that is our fault, not yours. Raise it as an issue on the repository, and we will fix the standard. Any other question can be raised the same way.

References

• myCroquet module kit repository