How to read this site

This wiki is organized from the outside in: first what users see, then the domain language, then architecture, data, code paths, operations, and references.

Page type	What it answers	Best for
Overview	What is this domain and who uses it?	Everyone
End-user view	What does the user do on screen?	Everyone, support
Core concepts	What are the main domain objects and terms?	Everyone
Architecture	What components and data stores are involved?	Engineers, architects
Codebase flow	Which files, APIs, services, and workers handle it?	Engineers
Common cases	What practical situations appear in support/debugging?	Engineers, support
References	Where are the source specs and code anchors?	Engineers

For the full page/domain matrix and its intentional exceptions, read the Wiki structure map.

Content contract

Each page type has one job: Overview provides orientation, End-user describes interaction, Concepts explains domain language and rules, Architecture/Data links explain the system, and Codebase/References provide traceability to source. When a page needs to mention another page's topic, summarize only what is needed and link to the owning page.

For a Common cases page, use this order: symptom/question → expected behavior → how to verify → source anchor → Real-world example. This lets support start from the observed symptom while giving engineers a clear path to the code and spec.

Page/link catalogs such as Reading path, Related, and Pages in this section use an ordered list or table so readers can reference items by number; use bullets for unordered facts, notes, and checklists.

Source of truth

This wiki summarizes the system. If it conflicts with reality, trust this order:

1. Actual code in Topi/, Tuke/, and Tux/ at the reviewed checkout
2. openspec/specs/**/spec.md for contract and business-rule verification
3. This wiki as the concise explanation

Applications mentioned often

Name	What it is	Role
Topi	Legacy React/UmiJS frontend	Older admin UI
Tuke	Next.js frontend	Modern web UI
Tux	.NET 8 backend and workers	APIs, business logic, queues, background processing

Reading against the current implementation

Pages with a Current implementation section mark behavior that exists in code; the VitePress page date is the latest page-update marker. For a new rule, read the Real-world example block immediately after it.

When code and OpenSpec differ, the wiki prioritizes running behavior and keeps unimplemented spec content out of user-facing documentation. Class, route, enum and anchor names remain unchanged so engineers can trace them back to code.