Files
MoShiro/AGENTS.md
T
justme 83e5120377 refactor!: rename the project from Monitor to MoShiro
Namespaces, assemblies, projects and directories, the solution, binaries,
images, systemd units, config paths, environment variables, protocol method
names, the media type and the raw chunk magic all move to MoShiro/moshiro.
Existing data and deployments are not compatible and must be recreated.
Also fix the architecture tests after the solution layout change and make
the update tests independent of their order.
2026-10-07 01:49:04 +08:00

3.7 KiB

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

  • Treat main as the stable release branch and dev as the integration branch. Keep ordinary implementation work on dev or a feature branch; integrate into main through a pull request.
  • A push to main builds 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. When squashing or pushing to main, add [CI] unless a build is explicitly not wanted.
  • 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, release_api_token with the release scope). 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/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. Development image builds and releases must remain isolated in their respective Zot repository paths.