MoShiro/AGENTS.md

Agent Instructions

Project

MoShiro is a self-hosted network path quality monitor. Backend coordinates Agents and Probes, stores measurements, and serves the REST/SSE API. web/display is the read-only overview; web/admin manages nodes, tests, and settings.

Branch and workspace safety

• main is the only working branch (the old dev branch is retired and no pipeline uses it). Commit and push to main directly; use a pull request when a review is wanted.
• A push to main publishes development images only if its commit message contains [CI] (for a merged PR, put it in the PR or merge commit title). Without [CI] nothing is built; use [CI SKIP] to skip the pipeline entirely. The fast Backend tests (verify) and the web build run on every main push and must pass first; the slow end-to-end tests ([Trait("Category", "Slow")]) run after the images are built and pushed (inside dev-image for [CI] pushes, workflow e2e otherwise) and never block them; [SKIP TESTS] skips only the Backend tests.
• Versions are filled in by CI (ci/version.sh): a vX.Y.Z tag builds exactly X.Y.Z; a [CI] build on main is vX.Y.(Z+1)-dev.<N>-<sha7> (N = commits since the latest tag). The <Version> in backend/Directory.Build.props and the version in the web package.json files are placeholders (0.0.0-dev); never bump them by hand.
• Before editing, inspect git status. Preserve pre-existing user changes: do not reset, clean, stash, or include unrelated files in a commit.
• Do not commit credentials, API keys, registry passwords, or generated runtime data. CI credentials belong in Woodpecker secrets (zot_secret, gitea_token, release_signing_key for signing release manifests). CI registers the signed manifests at /api/release/offer, which needs no token because the panel verifies the signature. The release signing private key never goes into the repository or the panel; only the public key in packaging/update/ does.
• Keep development OCI images in the moshiro-dev/ repository path and release images in moshiro/. Do not let a development build overwrite release tags such as latest.

Project layout

• backend/src/MoShiro.Backend/: service entry point and composition.
• backend/src/MoShiro.Backend.Api/: REST endpoints, contracts, and OpenAPI.
• backend/agent/, backend/probe/: node applications and their READMEs.
• backend/fleet/, backend/shared/: reusable node framework, measurement engine, protocols, and data formats.
• web/display/, web/admin/: Vite applications; web/shared/: API client, generated types, charts, and shared UI.
• packaging/, scripts/, .woodpecker/, docs/: container/package builds, CI workflows, and project documentation.

Local development and builds

Requirements: .NET SDK 10 and Node.js/npm. The SDK selection is defined by the root global.json; NuGet package versions are centralized in the root Directory.Packages.props.

• All .NET projects: dotnet build MoShiro.slnx -c Release from the repository root.
• Backend build: cd backend && dotnet build MoShiro.slnx -c Release
• Backend tests: cd backend && dotnet test --solution MoShiro.slnx -c Release
• Frontend dependencies/build: npm ci --prefix web && npm run build --prefix web
• Frontend style check: npm run lint:css --prefix web
• Local backend: from backend/, run dotnet run --project src/MoShiro.Backend -- --urls http://localhost:5000.
• Local web apps: from the repository root, run npm ci --prefix web then npm run dev --prefix web. The current dev config uses display port 5173 and admin port 5175; /admin/ is proxied through the display server. Check the Vite configs when working on another branch because ports can differ.
• After changing API contracts, regenerate/check backend/openapi/v1.json and run npm run gen:api --prefix web so frontend API types stay aligned.

Follow the user's requested validation scope. Do not start a full tag/release build unless requested.

CI and releases

CI triggers and image tags can change; inspect .woodpecker/*.yml and docs/ops/deployment.md before changing or describing them. In particular, check the distinction between [CI] main builds, [SKIP TESTS], and version-tag releases in the current branch.

A version tag vMAJOR.MINOR.PATCH runs the full cross-platform release pipeline; it needs no version-bump commit, because CI takes the version from the tag. Development image builds and releases must remain isolated in their respective Zot repository paths.