Developer reference · Protected-main baseline 805f3d6

Developer documentation

Build on the kernel without weakening its authority model.

The developer reference connects source code to accepted architecture decisions, module ownership, deterministic identities, application boundaries, refusal behavior, tests, and explicit non-claims.

Start here

Architecture

Dependency direction, authority ownership, canonical records, ports, adapters, UI boundaries, and the trust model.

Reference

Module map

Deep guides for the scientific, workflow, evidence, analysis, application, desktop, extension, and AI assemblies.

Contribute

Contributing

Source-of-truth order, gate workflow, test expectations, documentation standards, and safe change boundaries.

Architecture in one minute

Domain
authority and immutable records
Application
verified orchestration and commands
Infrastructure
files, CLI, desktop, future providers

Dependencies point inward. Domain assemblies do not reference EF Core, ASP.NET Core, Avalonia, provider SDKs, storage SDKs, or concrete model clients. UI state, file paths, database rows, and URLs are references or projections—not scientific identity.

Human authority stays explicit Application and UI code may invoke an accepted command. They cannot fabricate the actor, policy, evidence, protocol, or expected prior state that makes the command authoritative.

Fast paths

Build a surface

Keep renderer-neutral contracts, desktop orchestration, and scientific modules in their correct layers.

UI contracts · Desktop host

Verification baseline

dotnet restore NexusScholar.Core.slnx
dotnet build NexusScholar.Core.slnx -c Release --no-restore
dotnet test NexusScholar.Core.slnx -c Release --no-build
dotnet format NexusScholar.Core.slnx --verify-no-changes --no-restore
powershell -ExecutionPolicy Bypass -File ./scripts/verify.ps1

The repository-wide verifier also checks release policy, locked restore, package reproducibility, local-source package smoke, SBOM and release evidence, CLI smoke, and formatting.

Primary source order

  1. Approved files in specs/.
  2. Accepted ADRs in docs/adr/.
  3. Golden and conformance fixtures.
  4. Observable behavior of the pinned PHP reference.
  5. Current C# implementation.
  6. Informal notes, UI concepts, and comments.

When those sources conflict, record the conflict and stop the affected behavior until authority is resolved. Do not choose the most convenient interpretation.