Logic Lab has a closed V1 design baseline. Read each document according to its authority and subject; use the Implementation Plan for completion status instead of inferring delivery from a normative specification.
| Subject | Authority |
|---|---|
| system ownership, dependency direction, Module seams, deployment shape | ARCHITECTURE.md |
| workbench layout, interaction, visual language, responsive and accessibility behavior | WORKBENCH.md |
| domain words and context translations | CONTEXT-MAP.md and bounded-context glossaries |
| observable circuit, component, analysis, symbol, package, and policy behavior | specifications and policies |
| Application, browser, and HTTP seam values | seam contracts |
| ASP.NET Core routes, render modes, culture, circuits, security, and host operations | Web Host |
| Canvas/waveform transforms, frames, input, accessibility, and browser resources | Browser Runtime |
| .NET SDK, build, dependency, C#, async, DI, configuration, serialization, observability, and publication rules | .NET Engineering Baseline |
| delivery order, completion status, and blocking frontier | Implementation Plan |
| hard-to-reverse decision rationale | ADRs |
| evidence, derivation, alternatives, and source qualification | Research Index |
There is no generic “narrower file wins” rule. A specification defines current behavior, Architecture defines ownership and seams, Workbench defines experience, a contract defines values at one real seam, a glossary defines terminology, an ADR explains a choice, and research supplies evidence. A conflict is a documentation defect and must be repaired in the owning artifact.
Dynamic repository facts belong to executable configuration rather than prose:
| Fact | Source of truth |
|---|---|
| exact SDK and test runner | global.json |
| exact direct package versions | Directory.Packages.props |
| current executable project graph | logic-lab.slnx |
| resolved dependency closures | application-root packages.lock.json files |
Normative documents define the rules governing those files. Dated research may preserve an observed version or graph as historical evidence, but maintained prose does not copy a live inventory.
- Circuit Authoring
- Component Contract Catalog V1
- Compiler
- Simulation Runtime
- Boolean Analysis
.logiclabProject Package V1- Project Document JSON V1
- Diagnostics V1
- Diagram Presentation
- Web Host
- Browser Runtime
- .NET Engineering Baseline
- Policy Catalog
The Implementation Plan is the sole completion ledger and names the current dependency frontier. Each owning specification or contract defines its required evidence; the .NET Engineering Baseline defines reproducible repository gates. Routine verification snapshots belong in a change or CI record, not in maintained guidance. Passing those gates does not make the application V1-complete or production-qualified; the plan's Phase F slices own that qualification.
Engine Performance Benchmarks records production-shaped kernel, Compilation, and initial-settlement comparisons. It is directional performance evidence, not a release threshold.
Research preserves primary-source claims, mathematical reasoning, rejected alternatives, and qualification gaps. It is evidence, not a second implementation specification; project choices remain in the owning specification or ADR.
Research notes identify optional untracked standards copies by filename. When available, use pdftotext -layout for searchable prose and inspect original pages for figures and typography; do not treat those files as project assets.
- Define a fact once and link to it elsewhere.
- Use exact ubiquitous language from the glossaries.
- Keep framework, EF, JSON, SVG, and Fluent types out of Domain language.
- Keep runtime ordinals, storage chunks, algorithm nodes, and renderer details out of browser contracts.
- Add an ADR only for a genuine hard-to-reverse trade-off.
- Classify every number as semantic, format, provisional policy, or measured threshold.
- Cite primary sources at the claim; qualify secondary tutorials and Wikipedia as navigation only.
- Keep delivery status only in the Implementation Plan, required evidence in the owning specification or contract, reproducible commands in the .NET Engineering Baseline, and routine verification snapshots in change or CI records.
- Read exact SDK/package versions and the current project graph from root configuration; repeat them only in an explicitly dated research checkpoint.
- Frame time-sensitive implementation observations in research as dated checkpoint evidence, never as maintained current state.
- Update links and supersession notes in the same change that moves authority.