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

This commit is contained in:
dmg
2026-09-09 23:18:25 -04:00
parent 3bd2dc7d14
commit bf7f01a39e
18 changed files with 6 additions and 589 deletions
+5 -36
View File
@@ -1,40 +1,9 @@
# Spigot Quest Board Agent Guide
# spigot-quest-board agent entrypoint
## Project
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).
Spigot Quest Board is a Java 25 plugin for Purpur 26.2. It provides shared physical quest boards where players escrow rewards, deliver requested block items, and claim delivered or returned items.
Before work, read the sibling `../somc-okf/index.md`, `../somc-okf/processes/index.md`, `../somc-okf/projects/spigot-quest-board/index.md`, `engineering.md` in that project section, and relevant `../somc-okf/user-stories/spigot-quest-board/` stories. Also follow the parent workspace `AGENTS.md` when present.
## Canonical knowledge
For standalone checkouts, start at the [project page](https://git.garvis.dev/dmg/somc-okf/src/branch/main/projects/spigot-quest-board/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.
- `knowledge/` is the canonical OKF v0.1 knowledge bundle.
- Read `knowledge/index.md` and the relevant documents in `knowledge/user-stories/` before changing behavior.
- Every feature or behavior change requires an approved user story with task-list acceptance criteria.
- Preserve unknown YAML frontmatter fields when editing knowledge documents.
- Keep `knowledge/index.md`, `knowledge/log.md`, and `knowledge/user-stories/index.md` current.
## Development
- Compile against the Purpur API version declared in `build.gradle.kts`.
- Use Java 25 and enable strict compiler linting.
- Prefer small, server-independent domain objects and services that can be unit tested.
- Use test-driven development where practical: add a failing test, implement the minimum behavior, then refactor.
- Treat escrow, completion, cancellation, expiry, and claiming as atomic state transitions. Never duplicate or silently discard player items.
- Key players by UUID, not display name.
- Persist board, quest, escrow, and claim state safely across restarts using atomic file replacement where supported.
- Use UTC and RFC 3339 timestamps for persisted or documented date-times.
- Keep player-facing command autocomplete permission-aware and context-sensitive.
- Use Purpur's supported Paper dialog API for native dialog interfaces.
## Verification
Run before completing a story:
```bash
./gradlew clean check jar
```
Mark acceptance criteria complete only after implementation and verification.
## Git
Use conventional commits in the form `type(scope): description`, with summaries under 72 characters.
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.