chore(knowledge): move canonical docs to shared SoMC wiki

AGENTS.md

@@ -1,37 +1,9 @@
-# Project Agent Instructions
+# spigot-inventory-helper 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).
 
-- This repository contains the Spigot Inventory Helper plugin.
-- Target Purpur `26.2.build.2618-stable` with Java 25, matching `../spigot-base/` unless an approved user story changes the target.
-- Use Gradle with Kotlin DSL and the Gradle wrapper.
-- Keep compiler lint warnings enabled and fail builds on warnings, excluding only warnings explicitly justified by the supported API.
+Before work, read the sibling `../somc-okf/index.md`, `../somc-okf/processes/index.md`, `../somc-okf/projects/spigot-inventory-helper/index.md`, `engineering.md` in that project section, and relevant `../somc-okf/user-stories/spigot-inventory-helper/` stories. Also follow the parent workspace `AGENTS.md` when present.
 
-## Knowledge bundle
+For standalone checkouts, start at the [project page](https://git.garvis.dev/dmg/somc-okf/src/branch/main/projects/spigot-inventory-helper/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.
 
-- `design/` is the canonical OKF v0.1 knowledge bundle. Do not create a parallel `knowledge/` bundle.
-- Read `design/index.md`, the user-story catalog, relevant stories, and relevant implementation before changing behavior.
-- Every feature or behavior change must have a corresponding story under `design/user-stories/`.
-- Present proposed story additions or changes for review and wait for explicit approval before modifying stories or code.
-- Stories must have OKF frontmatter with `type: User Story`, a descriptive `title`, concise `description`, and one of `backlog`, `in-progress`, or `done` as `status`.
-- Stories must contain acceptance criteria using Markdown task-list items.
-- Set approved work to `in-progress` when implementation begins. Set it to `done` and check criteria only after implementation and verification.
-- Maintain standard Markdown links between the root index, story catalog, related stories, and other concepts.
-- Record material design and implementation decisions in `design/log.md`. Verify the current date before adding entries.
-
-## Development
-
-- Use test-driven development where practical: write a failing test, implement the minimum behavior, and refactor only while tests remain green.
-- Prefer small, cohesive Java types and server-independent logic that can be unit tested without a running Minecraft server.
-- Identify custom plugin items with persistent metadata rather than display names alone.
-- Preserve item quantities and metadata during inventory operations.
-- Respect Bukkit/Purpur event cancellation and protection-plugin decisions.
-- Run `./gradlew clean check jar` before marking implementation criteria complete.
-
-## Delivery
-
-- Model Gradle and Gitea Actions configuration on `../spigot-base/`, adapted to this plugin's names and identifiers.
-- Gitea workflows belong in `.gitea/workflows/`.
-- Pull requests must validate conventional commits, and main-branch conventional commits drive semantic releases.
-- Never commit generated Gradle output or plugin JARs.
-- Use conventional commit messages in the form `type(scope): description`, with a concise summary 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.