mikhail/LazyBearWorks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Сжать и уточнить AGENTS.md

Browse Source
This commit is contained in:
Михаил
2026-04-13 14:42:27 +03:00
parent b5eb33272a
commit 0290cb4102
1 changed files with 44 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
AGENTS.md
View File

@@ -1,35 +1,49 @@
# AGENTS.md
## AGENTS.md
## Scope
### Scope & Source of Truth
- Work in `LazyBear.MCP/`.
- Ignore `Libraries/Confluence/` unless the user explicitly asks for it.
- Trust code and project config over `README.md`.
- Primary source of truth: `LazyBear.MCP/Program.cs`.
- `LazyBearWorks.sln` builds exactly one project: `LazyBear.MCP/`. `Libraries/Confluence/` is present in the repo but is not part of the solution and has no `.csproj`; ignore it unless the user explicitly asks for it.
### Project Facts
- Entry point: `LazyBear.MCP/Program.cs`.
- MCP server registration:
```csharp
AddMcpServer()
.WithHttpTransport()
.WithToolsFromAssembly();
```
- Tools are auto-registered from the assembly.
- Current tool groups:
- `LazyBear.MCP/Services/Jira/`
- `LazyBear.MCP/Services/Kubernetes/`
- `Pages/` exists, but Razor Pages are not enabled in `Program.cs`.
- There are no test projects by default.
## Source Of Truth
### Commands
- Build: `dotnet build`
- Run: `dotnet run --project LazyBear.MCP`
- MCP inspector: `npx @modelcontextprotocol/inspector dotnet run --project LazyBear.MCP`
Use only when transport or tool registration changed.
- Trust `LazyBear.MCP/Program.cs` and project config over `README.md`. The README describes Razor Pages/UI and a broader tool surface, but the current app only configures MCP HTTP transport and auto-registers tool classes from the assembly.
### Config & Runtime Gotchas
- Runtime URL: `http://localhost:5000`
- `LazyBear.MCP/Properties/launchSettings.json` shows another port; trust `Program.cs`.
- SDK pin: `LazyBear.MCP/global.json`
- Main config: `LazyBear.MCP/appsettings.json`
- `Jira:Url` is required for Jira tools. If missing, provider init may fail and tools may return string errors.
- `Kubernetes:KubeconfigPath` may be empty. Fallback order:
1. explicit kubeconfig
2. default kubeconfig
3. in-cluster config
- Never print or commit real secrets, tokens, kubeconfig contents, or private URLs.
## Entry Points
- Main app entrypoint: `LazyBear.MCP/Program.cs`.
- Live MCP tools are discovered via `AddMcpServer().WithHttpTransport().WithToolsFromAssembly()`. Current tool classes are under `LazyBear.MCP/Services/Kubernetes/` and `LazyBear.MCP/Services/Jira/` and use `[McpServerToolType]`.
- Do not assume Razor Pages are active just because `Pages/` exists: `Program.cs` does not call `AddRazorPages()` or `MapRazorPages()`.
## Commands
- Build from repo root: `dotnet build`
- Build project directly: `dotnet build "LazyBear.MCP/LazyBear.MCP.csproj"`
- Run from repo root: `dotnet run --project "LazyBear.MCP"`
- MCP manual check: `npx @modelcontextprotocol/inspector dotnet run --project LazyBear.MCP`
- There are no test projects in the solution right now; default verification is `dotnet build`, plus a focused run/inspector check for transport or tool-registration changes.
## Runtime Quirks
- `LazyBear.MCP/Properties/launchSettings.json` says `http://localhost:5079`, but the app actually listens on `http://localhost:5000` because `Program.cs` hardcodes `app.Run("http://localhost:5000")`.
- SDK pin is in `LazyBear.MCP/global.json` (`10.0.100`), not at the repo root.
## Config Gotchas
- App config lives in `LazyBear.MCP/appsettings.json`.
- `Kubernetes:KubeconfigPath` defaults empty. `K8sClientFactory` then tries the default kubeconfig, then in-cluster config.
- Jira tools require `Jira:Url`; if it is empty, `JiraClientFactory` throws during provider setup. The app still starts because providers capture init errors and tools return those errors as strings.
- Treat `appsettings.json` values as potentially sensitive; do not commit real Jira tokens or cluster-specific settings.
### Working Rules
- Read related files before editing.
- Prefer minimal, non-breaking changes.
- Reuse existing patterns; avoid new abstractions without clear need.
- Verify behavior against code and config, not `README.md`.
- After changes, run `dotnet build`. If MCP wiring changed, also run the inspector.
- Output in Russian. Keep code in English. Keep comments and commit messages in Russian.
- If the request is broad or underspecified, ask one short clarifying question first. Otherwise act on the best reasonable assumption.