Build for MyCroquet

MyCroquet is the member app for Croquet Queensland. You likely have an idea for a new feature to help your club, but until now, the answer was usually a place in a queue. We now have a route that does not depend on that queue.

Version 1.0 of the public standard was published 4 September 2026. It allows you to build your own modules without needing access to the MyCroquet codebase. You can find the standard and the kit repository at https://github.com/automatebrisbaneai/mycroquet-module-kit.

The repository holds 23 files, as verified by gh repo view and a tree listing on 2026-09-04. It contains four things: STANDARD.md with the full standard, example/mycroquet-module-club-notices/ with a complete worked module, template/mycroquet-module-YOUR-ID/ as a blank skeleton to copy, and a submissions/ folder for finished packages sent via pull request.

The technical stack

The platform uses Next.js 16 with the App Router and React 19. Styling is handled by Tailwind CSS 4 and a shared component kit. TypeScript provides the type safety, and PocketBase is the database.

All members sign in at my.croquetqld.org by typing their email address to receive a code. The system uses no passwords and has no separate login for administrators.

How modules work

A module consists of one manifest file plus the pages and API routes it owns. The platform uses that manifest to derive the menu entry, the page guard, and the API guard. You do not need a separate registration step.

You must set enabled: false in the manifest. This is called shipping dark. A dark module is invisible in the menu, its pages redirect, and its API routes return 404.

There are about thirty modules in the app today and almost all of them shipped dark. This is the normal path rather than a special condition for outside work. Dark shipping allows us to accept your work before we decide who should see it, so your code does not sit waiting on a rollout decision. Switching the module on later is a one-line change.

Access is managed by capability tags. A capability tag is a named permission a person holds. Gates check for the tag rather than a job title, which is why a single person can be given access without changing anybody's role.

Every authenticated API route follows a strict sequence of three gates: the module gate, then authenticate, then authorise. This ensures the system knows the module is active and the user is allowed to be there before any data moves. Modules must live inside MyCroquet. We do not embed outside products in a frame and we do not open the login to outside sites.

Building your package

The repository provides a blank skeleton in template/mycroquet-module-YOUR-ID/. You should copy the structure and patterns from the worked example in example/mycroquet-module-club-notices/. There is no scaffold or generator command.

The example is real and proven. Its code was placed into the real MyCroquet staging checkout and type-checked on 2026-09-04 using npx tsc --noEmit, which produced no errors. Its unit test also ran in the real app. The command npx vitest run src/lib/club-notices.test.ts resulted in one test file passing with 3 tests passed in 641 ms.

If you use an AI agent, section 8 of the standard contains a prompt you can paste into the AI along with the rest of the document.

We tested this method with a fresh AI agent that had no access to the codebase. It produced a conforming package with API routes using the three gates in the correct order. During the process, it reported seven points where the standard was unclear or silent. Those seven points were fixed before publication.

The hand-over

You submit your finished package via a pull request to the submissions/ folder in the kit repository. Nothing you send touches the live app. We copy the folder into MyCroquet ourselves.

You must not edit any shared file. We handle registration and the creation of new capability tags at intake. Your deliverable must be one folder named mycroquet-module-<id>/ containing:

1. MODULE.md with eleven questions answered.
2. CHECKLIST.md with every item ticked and a line of evidence provided.
3. collections.json for any required database tables.
4. A src/ tree that mirrors the MyCroquet structure.
5. A tests/ folder.

Do not include any files outside these paths. The checklist requires evidence, not assertions. Writing "Tested" is not evidence. A valid entry is: "Ran npx vitest run src/lib/club-notices.test.ts, 3 passed".

Once a package arrives, we follow this intake order:

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

Wade Hart is the person who decides whether a module ships and who gets it. Capability tags are granted to people one at a time.

No third-party packages have been submitted yet. The first person to move through this process may find some rough edges. If you find a gap in the standard, you can raise it as an issue on the repository.