S19: own shared agent workflows and document multi-project runner onboarding

onboarding.md

@@ -4,11 +4,14 @@
    its responsibilities to systems.md; identify affected repositories in its
    specifications. Decide data ownership and deployment boundaries explicitly.
 2. Create a Gitea repository under the appropriate owner. Choose visibility
-   deliberately. Configure Actions and an available host runner with JDK 25,
+   deliberately. Enable Actions and use the shared host runner labelled `mini-pc`,
+   registered at user scope for `wanjakrah`, so new repositories of that owner
+   inherit access without a project-specific runner registration. It needs JDK 25,
    Maven, Git, Python 3, Docker/Compose and Node/npm when a frontend is selected.
 3. Clone [engineering](http://192.168.2.28:3000/wanjakrah/engineering) and check out
    a released version. Follow its README to run create-project.py with a project
-   name, destination, backend/frontend/both selection, release tag and runner label.
+   name, destination, backend/frontend/both selection and release tag. The default
+   runner label is `mini-pc`; override it only when using another shared runner.
 4. Review generated project-owned files, module paths, Compose project and image
    namespace. Configure deployment targets, readiness and any required dependency
    services. Keep secrets outside Git. Follow engineering's Gitea setup and
@@ -16,12 +19,19 @@
 5. Verify the engineering lock records both tag and full commit. Commit generated/
    with the local bootstrap and Maven profile. Confirm a fresh checkout builds
    and that the bootstrap can reconstruct an absent generated/ directory.
-6. Initialize and push the application repository, run its build workflow, and
+6. Before the first push, check that `mini-pc` is online and available in the new
+   repository's Actions settings. Follow engineering's runner verification command;
+   changing a workflow label alone does not change runner scope. Configure the
+   project's registry secrets and target platform separately.
+   Initialize and push the application repository, run its build workflow, and
    inspect diagnostics. Validate deployment/rollback in an isolated environment
    before a separate manual production deployment.
 7. Keep implementation and operational instructions in the application's README.
    Link README and AGENTS to this landscape and pinned local engineering guidance.
    Keep executable tests, fixtures and implementation validation evidence there.
+8. Verify that systems.md includes the new repository, responsibilities, data
+   ownership and deployment state. Record frontend technology deviations explicitly,
+   such as Waterpolo Coaching's Three.js and Vite instead of Angular.
 
 For engineering upgrades, choose a released tag, record its commit, follow that
 release's UPGRADING.md, regenerate and review the diff before committing. Only