Feat/integrate lightningeye

.claude/CLAUDE.md

@@ -0,0 +1,10 @@
+<!-- CODEGRAPH_START -->
+## CodeGraph
+
+In repositories indexed by CodeGraph (a `.codegraph/` directory exists at the repo root), reach for it BEFORE grep/find or reading files when you need to understand or locate code:
+
+- **MCP tool** (when available): `codegraph_explore` answers most code questions in one call — the relevant symbols' verbatim source plus the call paths between them, including dynamic-dispatch hops grep can't follow. Name a file or symbol in the query to read its current line-numbered source. If it's listed but deferred, load it by name via tool search.
+- **Shell** (always works): `codegraph explore "<symbol names or question>"` prints the same output.
+
+If there is no `.codegraph/` directory, skip CodeGraph entirely — indexing is the user's decision.
+<!-- CODEGRAPH_END -->

.claude/agent-memory/dotnet-blazor-expert/MEMORY.md

@@ -0,0 +1,5 @@
+# dotnet-blazor-expert memory index
+
+- [Quartz job wiring](project_quartz-job-wiring.md) — jobs registered only in Program.cs AddQuartz block; JobTypes.cs has no registry (stale CLAUDE.md claim)
+- [Migration header + verify.sh quirk](reference_migration-header-and-verify.md) — EF migrations skip the license header; verify.sh set -e false-fails on Spanish-locale build output
+- [.razor license header](reference_razor-license-header.md) — .razor files carry NO AGPL header; configuration-cs.json includes only .cs (skill template claim is wrong)

.claude/agent-memory/dotnet-blazor-expert/project_quartz-job-wiring.md

@@ -0,0 +1,12 @@
+---
+name: quartz-job-wiring
+description: How Quartz jobs are actually registered in NodeGuard, and a stale CLAUDE.md/skill claim to ignore
+metadata:
+  type: project
+---
+
+Quartz jobs are registered ONLY in `src/Program.cs` inside the `builder.Services.AddQuartz(q => { ... })` block, as paired `q.AddJob<T>(...)` + `q.AddTrigger(...)` calls. There is no job-type registry/enum to update.
+
+**Why:** CLAUDE.md and the migrate-lightningeye-backend skill both say to "wire the type through `src/Helpers/JobTypes.cs`". That is stale — `JobTypes.cs` contains only the `SimpleJob` / `RetriableJob` / `JobAndTrigger` helper classes (identical content to `SimpleJob.cs`), no enum or type map. Adding a job there is unnecessary and there is nothing to add.
+
+**How to apply:** When adding a scheduled monitor job, model it on `MonitorSwapsJob` (single `IJob` execution that iterates `INodeRepository.GetAllManagedByNodeGuard(false)` and injects repos/services directly), NOT `MonitorChannelsJob` (which fans out per-node sub-jobs via `SimpleJob.Create`). For dev/prod interval, the inline `if (Constants.IS_DEV_ENVIRONMENT) WithIntervalInMinutes(1) else WithIntervalInMinutes(10)` pattern (as in MonitorSwapsJob) is self-contained and additive — no new `Constants.*_CRON` needed. Mark `[DisallowConcurrentExecution]` on the class and also `opts.DisallowConcurrentExecution()` at registration. See [[verify-sh-set-e-quirk]].

.claude/agent-memory/dotnet-blazor-expert/reference_migration-header-and-verify.md

@@ -0,0 +1,14 @@
+---
+name: verify-sh-set-e-quirk
+description: EF migration license-header convention + the migrate-lightningeye verify.sh set -e false-failure
+metadata:
+  type: reference
+---
+
+Two gotchas confirmed while migrating the LightningEye backend:
+
+1. **EF-generated migrations do NOT carry the AGPLv3 license header** in this repo. Existing `src/Migrations/*.cs` (including Designer + ModelSnapshot) start straight with `using ...`. The `headache` check (configuration-cs.json) excludes them. So do not add the header to generated migration files — only to hand-written `.cs` in `src/` and `test/`.
+
+2. **`.claude/skills/migrate-lightningeye-backend/verify.sh` can exit 1 even when all checks pass.** It uses `set -euo pipefail`; step 1 pipes a quiet `dotnet build` into `grep -E "error|Error\(s\)|Build succeeded"`. On a Spanish-locale dotnet the success line is `Compilación correcta.` / `0 Errores`, which the grep does not match, so grep returns non-zero and `set -e` aborts. This is NOT a real failure.
+
+**How to apply:** To prove the slice, run the three steps manually instead of trusting verify.sh's exit code: `cd src && dotnet build`; `dotnet test --filter "FullyQualifiedName~PaymentRoute"` (expect 10 passed); `cd src && dotnet ef migrations has-pending-model-changes --context ApplicationDbContext` (expect "No changes have been made to the model"). See [[quartz-job-wiring]].

.claude/agent-memory/dotnet-blazor-expert/reference_razor-license-header.md

@@ -0,0 +1,19 @@
+---
+name: razor-license-header
+description: .razor files carry NO AGPLv3 header in this repo; configuration-cs.json includes only .cs
+metadata:
+  type: reference
+---
+
+`.razor` files do NOT get the AGPLv3 license header in NodeGuard. `configuration-cs.json`
+(the `headache` config driving `just add-license-cs`) has `includes: ["src/**/*.cs", "test/**/*.cs"]`
+— only `.cs`, not `.razor`. Sampled existing pages (AuditTrail, Channels, Wallets, Nodes) all
+start directly with `@page`, no header.
+
+**Why:** The header check tool only scans `.cs`. Running `just add-license-cs` is a no-op for
+`.razor` and would re-touch every `.cs` header (churn).
+
+**How to apply:** When creating a new `.razor` page, do NOT add a license header and do NOT run
+`just add-license-cs` for it. Only new `.cs` files under `src/`/`test/` (outside
+`src/Areas/Identity/Pages/`) need the header. This corrects skill/template claims that
+".razor files are covered too" — they are not. Complements [[migration-header-and-verify]].