dmg/purpur-heights
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 9 Wiki Activity

chore(knowledge): move canonical docs to shared SoMC wiki
CI / build (push) Successful in 1m21s
Details
Release / release (push) Successful in 2m3s
Details

Browse Source
This commit is contained in:
dmg
2026-09-09 23:18:13 -04:00
parent f011410b17
commit 82415ed501
13 changed files with 6 additions and 334 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+5 -14
View File
@@ -1,18 +1,9 @@
# Spigot Heights Agent Guide
# spigot-heights agent entrypoint
## Canonical design
The canonical stories, engineering guidance, and **all process documents** are in the private [SoMC OKF wiki](https://git.garvis.dev/dmg/somc-okf/src/branch/main/index.md).
- `design/` is the canonical OKF v0.1 knowledge bundle.
- Read relevant user stories before implementation and keep acceptance criteria and `design/log.md` synchronized with verified behavior.
Before work, read the sibling `../somc-okf/index.md`, `../somc-okf/processes/index.md`, `../somc-okf/projects/spigot-heights/index.md`, `engineering.md` in that project section, and relevant `../somc-okf/user-stories/spigot-heights/` stories. Also follow the parent workspace `AGENTS.md` when present.
## Engineering
For standalone checkouts, start at the [project page](https://git.garvis.dev/dmg/somc-okf/src/branch/main/projects/spigot-heights/index.md) and [shared process](https://git.garvis.dev/dmg/somc-okf/src/branch/main/processes/development.md). Obtain wiki access before feature work; do not recreate a local knowledge bundle. Source builds do not require private wiki access.
- Target Java 25 and Purpur `26.2.build.2618-stable`.
- Use Gradle Kotlin DSL and JUnit 5.
- Prefer small, server-independent domain classes with Bukkit adapters at the boundary.
- Develop test-first where practical and verify with `./gradlew clean check jar`.
- Treat custom item identity as persistent metadata; never trust display names.
- Validate all configuration before enabling gameplay behavior.
- Persist player data by UUID and use atomic replacement where supported.
- Keep event handlers on the server thread and avoid unnecessary work on player movement.
- Use conventional commits in the form `type(scope): description`.
Development follows [Development cycle](https://git.garvis.dev/dmg/somc-okf/src/branch/main/runbooks/development-cycle.md): approved stories, failing tests, passing implementation, verification, then source/wiki commit and push. GitOps updates are committed locally **without pushing**; only [Do release](https://git.garvis.dev/dmg/somc-okf/src/branch/main/runbooks/do-release.md) authorizes a reviewed GitOps push.