Eon

Eon은 사주 명리학, 베딕 점성학, 자미두수, 서양 점성술, 휴먼디자인, 기문 분석을 하나의 Rust 워크스페이스에서 다루는 운명 분석 플랫폼입니다. 이 저장소는 프론트엔드와 분석 엔진을 모두 Rust로 유지하며, Dioxus Web UI가 브라우저 Wasm에서 eon-service façade를 직접 호출합니다. 문서는 구현 상태를 설명하는 것을 목표로 하며, 분석 결과를 결정론적 진단이나 보장된 예측으로 과장하지 않습니다.

Live demo: eon-one.vercel.app
Primary language: Rust 2021
UI: Dioxus Web, WebAssembly, Tailwind CSS
Service boundary: crates/eon-service DTO and façade
Deployment target: Vercel static hosting

Eon treats traditional analysis systems as structured rule engines. The codebase favors explicit data models, reproducible calculations, and a thin integration layer over opaque generated output.

Project Scope
Current Architecture
Repository Map
Quick Start
Local Development
Workspace Crates
Service Facade
Frontend Architecture
State Management
DTO Construction
Async UI Calls
Domain Engines
Build and Deployment
Testing Strategy
Data and Time Handling
Internationalization
AI Audit Surface
Developer Guidelines
Contribution Checklist
Operational Notes
Roadmap
Glossary
Appendix A - Command Reference
Appendix B - Crate Inventory
Appendix C - Service Contract Notes
Appendix D - UI Maintenance Notes
Appendix E - Domain Notes
Appendix F - Release Notes Template
Appendix G - Troubleshooting
Appendix H - File Ownership Guide
Appendix I - Review Checklist
License

Project Scope

Eon is a Rust monorepo for experimenting with multiple symbolic analysis traditions through typed, testable modules.
The project is not a medical, legal, financial, or psychological decision system.
It does not claim that any tradition represented here is scientifically predictive.
It is useful as an engineering workspace for deterministic calculation, rule comparison, report generation, and UI exploration.
The current product surface is a browser SPA compiled from Rust to WebAssembly.
The current backend surface is not a separate web server; the Dioxus app calls Rust service code directly in the Wasm bundle.
Python files under api/ are auxiliary integration surfaces and are not the main product path.
TypeScript binding files under crates/eon-service/bindings exist for compatibility and contract inspection, but the active UI path is Rust.
Older React, Tauri, and npm assumptions should not be reintroduced.

Current Architecture

eon-core
  |
  +-- eon-data
  +-- eon-astro
  |
  +-- eon-saju
  +-- eon-vedic
  +-- eon-zwds
  +-- eon-western
  +-- eon-human-design
  +-- eon-qimen
  +-- eon-ai
        |
        v
    eon-service
        |
        v
    eon-ui (Dioxus Web / Wasm)

Layer	Responsibility	Notes
`eon-core`	Shared primitives	Birth data, locations, common error types.
`eon-data`	Calendar data	Binary manseryuk cache and related lookup helpers.
`eon-astro`	Astronomical calculations	Swiss Ephemeris oriented wrappers and position calculations.
Domain crates	Analysis engines	Saju, Vedic, ZWDS, Western, Human Design, Qimen, AI audit.
`eon-service`	Contract boundary	DTOs, constructors, façade functions, result types.
`eon-ui`	User interface	Dioxus components, global signal state, tab workflows.

The architecture intentionally keeps UI concerns outside the domain crates. UI components should gather input, call service façade functions asynchronously, and render returned DTOs.

Repository Map

Eon/
├── Cargo.toml
├── Cargo.lock
├── README.md
├── AGENTS.md
├── assets/
│   └── eon-logo.svg
├── api/
│   ├── ai_audit.py
│   └── mcp/
├── crates/
│   ├── eon-ai/
│   ├── eon-astro/
│   ├── eon-core/
│   ├── eon-data/
│   ├── eon-human-design/
│   ├── eon-qimen/
│   ├── eon-saju/
│   ├── eon-service/
│   ├── eon-ui/
│   ├── eon-vedic/
│   ├── eon-western/
│   └── eon-zwds/
├── docs/
├── scripts/
└── .github/workflows/

The workspace members are declared in the root Cargo.toml. Add new Rust crates there before expecting workspace commands to see them.

Quick Start

Prerequisites

Rust stable toolchain
wasm32-unknown-unknown target for web builds
Dioxus CLI 0.6.1 for the current CI path
A C toolchain capable of building native dependencies
WASI SDK when reproducing the Linux CI Wasm build path exactly

rustup toolchain install stable
rustup target add wasm32-unknown-unknown
cargo install dioxus-cli --version 0.6.1

Check the Workspace

cargo check --workspace

Run Focused Engine Tests

cargo test --package eon-saju
cargo test --package eon-vedic

Build the Dioxus UI

cd crates/eon-ui
cargo check
dx build
dx build --release

Do not use npm install, npm run dev, or npm run build for the active application. The current frontend is Rust/Dioxus, not React.

Local Development

Use cargo check -p eon-ui when touching UI wiring or DTO conversion.
Use cargo check --workspace before publishing cross-crate changes.
Use package-scoped tests when changing a specific engine.
Use Dioxus commands from crates/eon-ui because its Dioxus.toml is local to that crate.
Keep generated or derived output out of commits unless it is intentionally part of the repository contract.
Prefer small façade additions over direct UI calls into deep domain modules.
Prefer explicit constructors in eon_service::dto over struct literals in UI code.
Keep browser-facing operations asynchronous with spawn(async move { ... }).

Workspace Crates

Crate	Role	When to touch it
`crates/eon-core`	Common types for birth data, locations, errors, and shared primitives.	Use when defining cross-engine data that should not depend on a domain crate.
`crates/eon-data`	Manseryuk data and binary cache support.	Use when date conversion or lookup data belongs below analysis logic.
`crates/eon-astro`	Astronomical calculation boundary.	Use when a domain engine needs planetary or house positions.
`crates/eon-saju`	Saju engine with pillars, strength, yongshin, relationships, void, lints, and report structures.	Use for Korean/Chinese four pillars style analysis.
`crates/eon-vedic`	Vedic astrology engine with chart calculation, varga, dasha, yogas, KP, panchanga, and reports.	Use for sidereal chart workflows.
`crates/eon-zwds`	Zi Wei Dou Shu chart and period analysis.	Use for ZWDS-specific palace and star workflows.
`crates/eon-western`	Western astrology service logic.	Use for tropical or house-system oriented western workflows.
`crates/eon-human-design`	Human Design chart, connection, transit, return, Penta, and related structures.	Use for Human Design workflows.
`crates/eon-qimen`	Qimen builder and analysis modules.	Use for Qimen pan construction and reporting.
`crates/eon-ai`	AI audit support and tool-oriented integration surfaces.	Use for structured audit workflows, not as a replacement for deterministic engines.
`crates/eon-service`	Single service façade and DTO boundary.	Use as the default caller-facing API.
`crates/eon-ui`	Dioxus Web application.	Use for the browser experience and interaction flow.

crates/eon-core

Role: Common types for birth data, locations, errors, and shared primitives.
Maintenance rule: Use when defining cross-engine data that should not depend on a domain crate.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-data

Role: Manseryuk data and binary cache support.
Maintenance rule: Use when date conversion or lookup data belongs below analysis logic.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-astro

Role: Astronomical calculation boundary.
Maintenance rule: Use when a domain engine needs planetary or house positions.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-saju

Role: Saju engine with pillars, strength, yongshin, relationships, void, lints, and report structures.
Maintenance rule: Use for Korean/Chinese four pillars style analysis.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-vedic

Role: Vedic astrology engine with chart calculation, varga, dasha, yogas, KP, panchanga, and reports.
Maintenance rule: Use for sidereal chart workflows.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-zwds

Role: Zi Wei Dou Shu chart and period analysis.
Maintenance rule: Use for ZWDS-specific palace and star workflows.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-western

Role: Western astrology service logic.
Maintenance rule: Use for tropical or house-system oriented western workflows.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-human-design

Role: Human Design chart, connection, transit, return, Penta, and related structures.
Maintenance rule: Use for Human Design workflows.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-qimen

Role: Qimen builder and analysis modules.
Maintenance rule: Use for Qimen pan construction and reporting.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-ai

Role: AI audit support and tool-oriented integration surfaces.
Maintenance rule: Use for structured audit workflows, not as a replacement for deterministic engines.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-service

Role: Single service façade and DTO boundary.
Maintenance rule: Use as the default caller-facing API.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

crates/eon-ui

Role: Dioxus Web application.
Maintenance rule: Use for the browser experience and interaction flow.
Keep public types stable when they are returned through eon-service.
Add focused tests near the crate that owns the changed behavior.
Avoid pulling UI concerns into this layer.

Service Facade

The intended integration point is crates/eon-service/src/facade.rs.

use eon_service::dto::{AnalysisInput, SajuAnalysisInput};
use eon_service::facade::analyze_saju;

let base = AnalysisInput {
    year: 1990,
    month: 5,
    day: 15,
    hour: 10,
    minute: 0,
    is_lunar: false,
    is_leap_month: false,
    lat: 37.5665,
    lon: 126.9780,
    timezone: "Asia/Seoul".to_string(),
};

let input = SajuAnalysisInput::new(base, true, false, None);
let output = analyze_saju(input)?;
println!("{:?}", output.meta);

Function	Input	Output
`analyze_saju`	`SajuAnalysisInput`	`SajuAnalysisOutput`
`analyze_vedic`	`VedicAnalysisInput`	`VedicAnalysisOutput`
`analyze_vedic_compatibility`	`VedicCompatibilityInput`	`VedicCompatibilityOutput`
`analyze_zwds`	`ZwdsAnalysisInput`	`ZwdsAnalysisOutput`
`analyze_qimen`	`QimenAnalysisInput`	`QimenAnalysisOutput`
`analyze_transit`	`TransitAnalysisInput`	`TransitAnalysisOutput`
`analyze_ai_audit`	`SajuAnalysisInput`	`AiAuditOutput`
`analyze_destiny_tier`	Saju, Vedic, optional transit outputs	`TierResult`
`analyze_iching`	`SajuAnalysisInput`	`IChingAnalysisOutput`
`analyze_western`	`WesternAnalysisInput`	`WesternAnalysisOutput`
`analyze_human_design`	`HumanDesignAnalysisInput`	`HumanDesignAnalysisOutput`
`analyze_hd_connection`	two Human Design inputs	connection result
`analyze_hd_transit`	natal input plus transit time	transit result
`analyze_hd_return`	natal input, return type, target year	return result
`analyze_hd_penta`	group inputs	Penta result
`generate_themed_report`	`ThemedReportInput`	`ThemedReportOutput`

Frontend Architecture

The active frontend is crates/eon-ui, a Dioxus Web SPA.

Path	Purpose
`src/main.rs`	Application entry and top-level Dioxus setup.
`src/router.rs`	Dioxus Router configuration.
`src/store/mod.rs`	Global `AnalysisState` and form state.
`src/components/layout`	Application layout components.
`src/components/shared`	Reusable form and export components.
`src/components/tabs`	Domain-specific analysis tabs.
`src/i18n`	Locale data and translation helpers.
`src/utils`	Geocoding and binary city data helpers.
`public`	Static files copied into Dioxus builds.

The Dioxus release output is configured as target/dx/eon-ui/release/web/public.

State Management

All analysis results in the UI should flow through AnalysisState in crates/eon-ui/src/store/mod.rs.

let mut state = use_context::<AnalysisState>();
let form = state.form.read().clone();
state.saju.write().status = TaskStatus::Loading;

Do not reintroduce Zustand or React-era state patterns.
Do not store parallel analysis result copies outside the signal state unless there is a narrow UI-only reason.
When adding a new analysis tab, add a typed AnalysisTaskState<T> field to AnalysisState.
When reading form input for service calls, clone the form state before entering an async task.

DTO Construction

Use constructor functions from eon_service::dto for domain-specific input wrappers.

DTO	Constructor	Notes
`SajuAnalysisInput`	`SajuAnalysisInput::new(base, is_male, use_night_rat_hour, unknown_time)`	Maps unknown time to `BirthTimePrecision`.
`TransitAnalysisInput`	`TransitAnalysisInput::new(base, now_utc)`	Captures current UTC context and analysis timezone.
`VedicAnalysisInput`	`VedicAnalysisInput::new(base, unknown_time, now_utc)`	Stores precision and current context.
`ZwdsAnalysisInput`	`ZwdsAnalysisInput::new(base, is_male, target_year)`	Adds gender and optional target year.
`QimenAnalysisInput`	`QimenAnalysisInput::new(base, is_male)`	Defaults night rat hour flag to false.
`WesternAnalysisInput`	`WesternAnalysisInput::new(base, house_system)`	House system remains caller-selected.
`HumanDesignAnalysisInput`	`HumanDesignAnalysisInput::new(base)`	Uses only the shared birth input.

UI code should use FormState::to_analysis_input() as the base conversion point.

Async UI Calls

Heavy analysis should run inside Dioxus async tasks.

let mut state = use_context::<AnalysisState>();
let form = state.form.read().clone();
spawn(async move {
    let base = form.to_analysis_input();
    let input = SajuAnalysisInput::new(base, form.is_male, form.use_night_rat_hour, None);
    let result = eon_service::facade::analyze_saju(input);
    match result {
        Ok(data) => {
            state.saju.write().data = Some(data);
            state.saju.write().status = TaskStatus::Success;
        }
        Err(err) => {
            state.saju.write().status = TaskStatus::Error(err.to_string());
        }
    }
});

Do not call long-running analysis directly inside rsx!.
Keep loading, success, and error states explicit.
Use typed result slots in AnalysisState rather than loosely typed maps.
Prefer service façade calls over importing deep engine modules into components.

Domain Engines

Saju

Four pillars calculation and report structures.
Strength, yongshin, transformations, void, relationships, dynamic luck, and structural diagnostics.
Includes engineering-inspired modules such as VM, linter, topology, entropy, and fuzzer.

Vedic

Sidereal chart calculation and report generation.
Varga, nakshatra, shadbala, ashtakavarga, yogas, dasha, panchanga, KP, Tajika, and gochara support.
Regression tests use fixture files under crates/eon-vedic/tests/fixtures.

ZWDS

Zi Wei Dou Shu chart construction and period calculations.
Uses palace, star, brightness, annual, decadal, and transformation modules.
Outputs are surfaced through ZwdsAnalysisOutput.

Western

Western astrology service boundary.
House system is passed through the DTO as a string code.
Keep western-specific calculations in the western crate or service module.

Human Design

Chart, connection, transit, return, dream rave, PHS, Penta, and bodygraph related modules.
The UI includes multiple Human Design tabs and visual components.
Group workflows should preserve typed inputs rather than flattening participants into unstructured JSON.

Qimen

Builder modules construct the pan and ju.
Analysis report logic belongs under crates/eon-qimen/src/analysis.
The service façade exposes analyze_qimen.

AI Audit

Auxiliary audit surface for structured interpretation checks.
Should augment deterministic outputs rather than replace them.
Keep prompts and audit tooling explicit and reviewable.

Build and Deployment

CI

The main CI workflow lives at .github/workflows/ci.yml.

Format and Clippy run across the workspace.
Tests and coverage use cargo llvm-cov.
The Wasm build job installs Dioxus CLI 0.6.1 and builds the web app.
The workflow targets main pushes and pull requests.

Vercel Deployment

The deployment workflow lives at .github/workflows/deploy.yml.

It runs on pushes to main and manual dispatch.
It installs the wasm32-unknown-unknown target.
It runs a direct Wasm cargo build for debugging cargo errors.
It runs dx build --release --trace from crates/eon-ui.
It copies public/vercel.json into the release output.
It generates a minified Tailwind CSS file after the Dioxus build.
It deploys target/dx/eon-ui/release/web/public to Vercel.

Release Output

target/dx/eon-ui/release/web/public

This path is the static artifact root used by the Vercel deployment step.

Testing Strategy

Use narrow package checks first when touching a single engine.
Use workspace checks when service DTOs, shared types, or UI integration changed.
Use Vedic regression fixtures when modifying astronomical or Vedic calculation behavior.
Treat a successful compile as necessary but not sufficient for semantic changes.
When a UI tab changes DTO semantics, validate the data path from FormState to the façade call.
When changing deployment, inspect both ci.yml and deploy.yml.

cargo check -p eon-ui
cargo check --workspace
cargo test --package eon-saju
cargo test --package eon-vedic

Data and Time Handling

AnalysisInput stores date, time, lunar flags, coordinates, and timezone.
Timezone should be an IANA string such as Asia/Seoul.
Unknown birth time is represented by BirthTimePrecision::UnknownTimeNoonProxy through constructors.
The UI currently defaults to Seoul coordinates and Asia/Seoul through FormState.
Current-time dependent workflows should pass through CurrentContext.
Historical calendar and timezone behavior should be tested with explicit fixtures when changed.

Internationalization

Locale files live under crates/eon-ui/src/i18n.
Current locale state is stored in AnalysisState::locale.
Keep labels and interpretation text separate from calculation logic.
When adding a UI label, add or update locale entries together with the component change.
Avoid embedding long translated strings directly in domain crates.

AI Audit Surface

eon-ai and analyze_ai_audit are auxiliary analysis surfaces.
Audit output should be treated as review support, not as the source of truth for core calculations.
When AI-related output references deterministic analysis, preserve the structured link to the source result.
Keep any prompt-like text auditable and version-controlled.

Developer Guidelines

Keep the service layer as the single public integration boundary for the UI.
Use AnalysisState for all UI analysis results.
Use DTO constructors instead of directly filling every wrapper field.
Run heavy analysis through spawn(async move { ... }) in Dioxus components.
Do not reintroduce React, Tauri, Zustand, or npm-based frontend workflows.
Do not recreate an eon-wasm JSON bridge for the active app path.
Prefer clear, typed structs over ad hoc JSON blobs.
Prefer small domain-specific tests near changed code.
Keep calculation code deterministic where possible.
Document assumptions when rule systems differ by school or tradition.
Avoid claiming more precision than the input data supports.
Expose uncertainty explicitly in reports when time or location input is approximate.
Keep assets small enough for the Wasm/static deployment path.
Use rg to find existing patterns before adding new abstractions.
Review generated TypeScript bindings only if a task specifically touches external JS consumers.

Contribution Checklist

The change is scoped to the owning crate or layer.
Public DTO changes are reflected in eon-service.
UI state changes are reflected in AnalysisState.
Dioxus components call service functions asynchronously.
No npm or React-era build commands were introduced.
Focused tests or checks were run.
Workspace check was run for cross-crate changes.
README or DOCS were updated when behavior changed.
CI and deployment workflows still match the intended build path.
The final commit contains only related changes.

Operational Notes

The live deployment is expected to be static Vercel hosting.
The app bundle includes Rust/Wasm logic, so binary size matters.
Tailwind CSS is generated during CI deployment rather than through npm scripts.
The CI workflow has explicit Wasm build coverage to catch browser-target errors.
The repository version in Cargo.toml is currently 0.1.2 for the workspace package metadata.
There is no root LICENSE file in the current tree even though workspace metadata says MIT. Add one before depending on license discovery tooling.

Roadmap

Horizon	Item
Short term	Keep DTO construction consistent across all UI tabs.
Short term	Reduce duplicated form handling between primary and secondary person workflows.
Short term	Keep focused regression tests for date, timezone, and unknown-time behavior.
Medium term	Improve typed report sections so UI rendering does not need fragile string parsing.
Medium term	Add clearer fixture coverage for cross-engine tier analysis.
Medium term	Document school-specific rule choices in domain docs.
Long term	Separate optional heavy assets from the initial web bundle where practical.
Long term	Add stable public examples for service consumers.

Glossary

Term	Meaning
AnalysisInput	Shared birth/time/location DTO used as the base for service requests.
AnalysisState	Dioxus signal context that stores form values and analysis task states.
BirthTimePrecision	Enum that records exact time versus unknown-time noon proxy.
Dioxus	Rust UI framework used for the browser SPA.
Façade	The public service entry point in `eon-service/src/facade.rs`.
Manseryuk	Calendar dataset used for lunisolar date handling.
Saju	Four pillars analysis tradition.
Varga	Vedic divisional chart concept.
Wasm	WebAssembly target for the Dioxus frontend.
ZWDS	Zi Wei Dou Shu analysis system.

Appendix A - Command Reference

Task	Command
Workspace check	`cargo check --workspace`
UI check	`cargo check -p eon-ui`
Saju tests	`cargo test --package eon-saju`
Vedic tests	`cargo test --package eon-vedic`
Dioxus development build	`cd crates/eon-ui && dx build`
Dioxus release build	`cd crates/eon-ui && dx build --release`
CI-equivalent formatting check	`cargo fmt --all -- --check`
CI-equivalent clippy check	`cargo clippy --workspace --all-targets -- -D warnings`

Command note 001: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 002: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 003: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 004: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 005: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 006: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 007: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 008: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 009: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 010: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 011: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 012: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 013: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 014: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 015: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 016: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 017: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 018: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 019: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 020: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 021: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 022: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 023: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 024: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 025: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 026: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 027: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 028: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 029: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 030: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 031: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 032: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 033: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 034: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 035: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 036: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 037: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 038: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 039: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 040: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 041: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 042: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 043: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 044: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 045: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 046: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 047: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 048: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 049: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 050: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 051: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 052: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 053: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 054: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 055: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 056: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 057: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 058: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 059: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 060: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 061: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 062: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 063: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 064: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 065: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 066: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 067: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 068: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 069: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 070: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 071: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 072: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 073: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 074: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 075: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 076: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 077: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 078: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 079: prefer the narrowest command that validates the changed layer before running broader workspace checks.
Command note 080: prefer the narrowest command that validates the changed layer before running broader workspace checks.

Appendix B - Crate Inventory

B.01 eon-core

Path: crates/eon-core
Primary role: Common types for birth data, locations, errors, and shared primitives.
Edit trigger: Use when defining cross-engine data that should not depend on a domain crate.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.02 eon-data

Path: crates/eon-data
Primary role: Manseryuk data and binary cache support.
Edit trigger: Use when date conversion or lookup data belongs below analysis logic.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.03 eon-astro

Path: crates/eon-astro
Primary role: Astronomical calculation boundary.
Edit trigger: Use when a domain engine needs planetary or house positions.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.04 eon-saju

Path: crates/eon-saju
Primary role: Saju engine with pillars, strength, yongshin, relationships, void, lints, and report structures.
Edit trigger: Use for Korean/Chinese four pillars style analysis.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.05 eon-vedic

Path: crates/eon-vedic
Primary role: Vedic astrology engine with chart calculation, varga, dasha, yogas, KP, panchanga, and reports.
Edit trigger: Use for sidereal chart workflows.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.06 eon-zwds

Path: crates/eon-zwds
Primary role: Zi Wei Dou Shu chart and period analysis.
Edit trigger: Use for ZWDS-specific palace and star workflows.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.07 eon-western

Path: crates/eon-western
Primary role: Western astrology service logic.
Edit trigger: Use for tropical or house-system oriented western workflows.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.08 eon-human-design

Path: crates/eon-human-design
Primary role: Human Design chart, connection, transit, return, Penta, and related structures.
Edit trigger: Use for Human Design workflows.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.09 eon-qimen

Path: crates/eon-qimen
Primary role: Qimen builder and analysis modules.
Edit trigger: Use for Qimen pan construction and reporting.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.10 eon-ai

Path: crates/eon-ai
Primary role: AI audit support and tool-oriented integration surfaces.
Edit trigger: Use for structured audit workflows, not as a replacement for deterministic engines.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.11 eon-service

Path: crates/eon-service
Primary role: Single service façade and DTO boundary.
Edit trigger: Use as the default caller-facing API.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.

B.12 eon-ui

Path: crates/eon-ui
Primary role: Dioxus Web application.
Edit trigger: Use for the browser experience and interaction flow.
Review concern: public data shape, tests, and service boundary compatibility.
Validation: start with package-local checks, then workspace checks if public types changed.
Inventory note 001: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 002: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 003: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 004: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 005: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 006: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 007: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 008: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 009: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 010: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 011: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 012: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 013: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 014: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 015: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 016: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 017: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 018: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 019: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 020: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 021: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 022: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 023: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 024: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 025: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 026: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 027: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 028: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 029: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 030: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 031: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 032: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 033: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 034: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 035: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 036: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 037: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 038: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 039: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 040: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 041: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 042: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 043: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 044: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 045: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 046: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 047: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 048: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 049: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 050: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 051: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 052: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 053: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 054: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 055: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 056: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 057: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 058: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 059: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 060: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 061: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 062: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 063: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 064: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 065: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 066: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 067: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 068: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 069: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 070: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 071: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 072: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 073: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 074: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 075: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 076: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 077: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 078: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 079: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 080: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 081: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 082: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 083: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 084: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 085: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 086: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 087: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 088: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 089: eon-vedic should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 090: eon-zwds should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 091: eon-western should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 092: eon-human-design should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 093: eon-qimen should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 094: eon-ai should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 095: eon-service should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 096: eon-ui should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 097: eon-core should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 098: eon-data should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 099: eon-astro should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.
Inventory note 100: eon-saju should remain aligned with its owning layer and avoid leaking unrelated UI or deployment assumptions.

Appendix C - Service Contract Notes

Contract 01: analyze_saju accepts SajuAnalysisInput and returns SajuAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 02: analyze_vedic accepts VedicAnalysisInput and returns VedicAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 03: analyze_vedic_compatibility accepts VedicCompatibilityInput and returns VedicCompatibilityOutput; callers should treat the façade as the stable boundary.
Contract 04: analyze_zwds accepts ZwdsAnalysisInput and returns ZwdsAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 05: analyze_qimen accepts QimenAnalysisInput and returns QimenAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 06: analyze_transit accepts TransitAnalysisInput and returns TransitAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 07: analyze_ai_audit accepts SajuAnalysisInput and returns AiAuditOutput; callers should treat the façade as the stable boundary.
Contract 08: analyze_destiny_tier accepts Saju, Vedic, optional transit outputs and returns TierResult; callers should treat the façade as the stable boundary.
Contract 09: analyze_iching accepts SajuAnalysisInput and returns IChingAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 10: analyze_western accepts WesternAnalysisInput and returns WesternAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 11: analyze_human_design accepts HumanDesignAnalysisInput and returns HumanDesignAnalysisOutput; callers should treat the façade as the stable boundary.
Contract 12: analyze_hd_connection accepts two Human Design inputs and returns connection result; callers should treat the façade as the stable boundary.
Contract 13: analyze_hd_transit accepts natal input plus transit time and returns transit result; callers should treat the façade as the stable boundary.
Contract 14: analyze_hd_return accepts natal input, return type, target year and returns return result; callers should treat the façade as the stable boundary.
Contract 15: analyze_hd_penta accepts group inputs and returns Penta result; callers should treat the façade as the stable boundary.
Contract 16: generate_themed_report accepts ThemedReportInput and returns ThemedReportOutput; callers should treat the façade as the stable boundary.
Service note 001: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 002: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 003: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 004: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 005: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 006: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 007: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 008: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 009: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 010: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 011: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 012: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 013: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 014: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 015: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 016: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 017: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 018: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 019: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 020: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 021: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 022: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 023: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 024: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 025: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 026: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 027: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 028: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 029: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 030: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 031: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 032: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 033: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 034: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 035: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 036: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 037: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 038: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 039: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 040: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 041: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 042: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 043: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 044: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 045: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 046: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 047: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 048: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 049: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 050: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 051: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 052: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 053: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 054: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 055: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 056: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 057: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 058: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 059: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 060: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 061: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 062: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 063: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 064: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 065: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 066: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 067: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 068: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 069: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 070: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 071: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 072: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 073: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 074: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 075: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 076: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 077: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 078: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 079: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 080: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 081: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 082: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 083: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 084: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 085: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 086: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 087: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 088: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 089: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 090: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 091: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 092: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 093: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 094: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 095: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 096: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 097: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 098: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 099: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.
Service note 100: prefer constructor-backed DTO assembly so precision, current context, and default flags stay centralized.

Appendix D - UI Maintenance Notes

UI note 001: State reads should be short-lived.
UI note 002: Clone form state before async work.
UI note 003: Write loading state before starting expensive work.
UI note 004: Store errors as strings only at the UI boundary.
UI note 005: Keep domain display logic separate from service calculation.
UI note 006: Avoid doing calculation inside rsx!.
UI note 007: Use shared components for birth forms.
UI note 008: Keep export behavior in shared components.
UI note 009: Check mobile layout when adding tab content.
UI note 010: Keep i18n labels in locale modules.
UI note 011: State reads should be short-lived.
UI note 012: Clone form state before async work.
UI note 013: Write loading state before starting expensive work.
UI note 014: Store errors as strings only at the UI boundary.
UI note 015: Keep domain display logic separate from service calculation.
UI note 016: Avoid doing calculation inside rsx!.
UI note 017: Use shared components for birth forms.
UI note 018: Keep export behavior in shared components.
UI note 019: Check mobile layout when adding tab content.
UI note 020: Keep i18n labels in locale modules.
UI note 021: State reads should be short-lived.
UI note 022: Clone form state before async work.
UI note 023: Write loading state before starting expensive work.
UI note 024: Store errors as strings only at the UI boundary.
UI note 025: Keep domain display logic separate from service calculation.
UI note 026: Avoid doing calculation inside rsx!.
UI note 027: Use shared components for birth forms.
UI note 028: Keep export behavior in shared components.
UI note 029: Check mobile layout when adding tab content.
UI note 030: Keep i18n labels in locale modules.
UI note 031: State reads should be short-lived.
UI note 032: Clone form state before async work.
UI note 033: Write loading state before starting expensive work.
UI note 034: Store errors as strings only at the UI boundary.
UI note 035: Keep domain display logic separate from service calculation.
UI note 036: Avoid doing calculation inside rsx!.
UI note 037: Use shared components for birth forms.
UI note 038: Keep export behavior in shared components.
UI note 039: Check mobile layout when adding tab content.
UI note 040: Keep i18n labels in locale modules.
UI note 041: State reads should be short-lived.
UI note 042: Clone form state before async work.
UI note 043: Write loading state before starting expensive work.
UI note 044: Store errors as strings only at the UI boundary.
UI note 045: Keep domain display logic separate from service calculation.
UI note 046: Avoid doing calculation inside rsx!.
UI note 047: Use shared components for birth forms.
UI note 048: Keep export behavior in shared components.
UI note 049: Check mobile layout when adding tab content.
UI note 050: Keep i18n labels in locale modules.
UI note 051: State reads should be short-lived.
UI note 052: Clone form state before async work.
UI note 053: Write loading state before starting expensive work.
UI note 054: Store errors as strings only at the UI boundary.
UI note 055: Keep domain display logic separate from service calculation.
UI note 056: Avoid doing calculation inside rsx!.
UI note 057: Use shared components for birth forms.
UI note 058: Keep export behavior in shared components.
UI note 059: Check mobile layout when adding tab content.
UI note 060: Keep i18n labels in locale modules.
UI note 061: State reads should be short-lived.
UI note 062: Clone form state before async work.
UI note 063: Write loading state before starting expensive work.
UI note 064: Store errors as strings only at the UI boundary.
UI note 065: Keep domain display logic separate from service calculation.
UI note 066: Avoid doing calculation inside rsx!.
UI note 067: Use shared components for birth forms.
UI note 068: Keep export behavior in shared components.
UI note 069: Check mobile layout when adding tab content.
UI note 070: Keep i18n labels in locale modules.
UI note 071: State reads should be short-lived.
UI note 072: Clone form state before async work.
UI note 073: Write loading state before starting expensive work.
UI note 074: Store errors as strings only at the UI boundary.
UI note 075: Keep domain display logic separate from service calculation.
UI note 076: Avoid doing calculation inside rsx!.
UI note 077: Use shared components for birth forms.
UI note 078: Keep export behavior in shared components.
UI note 079: Check mobile layout when adding tab content.
UI note 080: Keep i18n labels in locale modules.
UI note 081: State reads should be short-lived.
UI note 082: Clone form state before async work.
UI note 083: Write loading state before starting expensive work.
UI note 084: Store errors as strings only at the UI boundary.
UI note 085: Keep domain display logic separate from service calculation.
UI note 086: Avoid doing calculation inside rsx!.
UI note 087: Use shared components for birth forms.
UI note 088: Keep export behavior in shared components.
UI note 089: Check mobile layout when adding tab content.
UI note 090: Keep i18n labels in locale modules.
UI note 091: State reads should be short-lived.
UI note 092: Clone form state before async work.
UI note 093: Write loading state before starting expensive work.
UI note 094: Store errors as strings only at the UI boundary.
UI note 095: Keep domain display logic separate from service calculation.
UI note 096: Avoid doing calculation inside rsx!.
UI note 097: Use shared components for birth forms.
UI note 098: Keep export behavior in shared components.
UI note 099: Check mobile layout when adding tab content.
UI note 100: Keep i18n labels in locale modules.
UI note 101: State reads should be short-lived.
UI note 102: Clone form state before async work.
UI note 103: Write loading state before starting expensive work.
UI note 104: Store errors as strings only at the UI boundary.
UI note 105: Keep domain display logic separate from service calculation.
UI note 106: Avoid doing calculation inside rsx!.
UI note 107: Use shared components for birth forms.
UI note 108: Keep export behavior in shared components.
UI note 109: Check mobile layout when adding tab content.
UI note 110: Keep i18n labels in locale modules.
UI note 111: State reads should be short-lived.
UI note 112: Clone form state before async work.
UI note 113: Write loading state before starting expensive work.
UI note 114: Store errors as strings only at the UI boundary.
UI note 115: Keep domain display logic separate from service calculation.
UI note 116: Avoid doing calculation inside rsx!.
UI note 117: Use shared components for birth forms.
UI note 118: Keep export behavior in shared components.
UI note 119: Check mobile layout when adding tab content.
UI note 120: Keep i18n labels in locale modules.
UI note 121: State reads should be short-lived.
UI note 122: Clone form state before async work.
UI note 123: Write loading state before starting expensive work.
UI note 124: Store errors as strings only at the UI boundary.
UI note 125: Keep domain display logic separate from service calculation.
UI note 126: Avoid doing calculation inside rsx!.
UI note 127: Use shared components for birth forms.
UI note 128: Keep export behavior in shared components.
UI note 129: Check mobile layout when adding tab content.
UI note 130: Keep i18n labels in locale modules.
UI note 131: State reads should be short-lived.
UI note 132: Clone form state before async work.
UI note 133: Write loading state before starting expensive work.
UI note 134: Store errors as strings only at the UI boundary.
UI note 135: Keep domain display logic separate from service calculation.
UI note 136: Avoid doing calculation inside rsx!.
UI note 137: Use shared components for birth forms.
UI note 138: Keep export behavior in shared components.
UI note 139: Check mobile layout when adding tab content.
UI note 140: Keep i18n labels in locale modules.
UI note 141: State reads should be short-lived.
UI note 142: Clone form state before async work.
UI note 143: Write loading state before starting expensive work.
UI note 144: Store errors as strings only at the UI boundary.
UI note 145: Keep domain display logic separate from service calculation.
UI note 146: Avoid doing calculation inside rsx!.
UI note 147: Use shared components for birth forms.
UI note 148: Keep export behavior in shared components.
UI note 149: Check mobile layout when adding tab content.
UI note 150: Keep i18n labels in locale modules.

Appendix E - Domain Notes

Domain note 001: When a rule system has variants, name the selected convention.
Domain note 002: When a result depends on unknown time, surface that limitation.
Domain note 003: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 004: When adding a new score, document its scale and interpretation.
Domain note 005: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 006: When adding fixtures, make input data and expected output easy to audit.
Domain note 007: When deriving a report from multiple engines, keep source fields traceable.
Domain note 008: When changing calendar logic, add regression cases around boundary dates.
Domain note 009: When a rule system has variants, name the selected convention.
Domain note 010: When a result depends on unknown time, surface that limitation.
Domain note 011: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 012: When adding a new score, document its scale and interpretation.
Domain note 013: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 014: When adding fixtures, make input data and expected output easy to audit.
Domain note 015: When deriving a report from multiple engines, keep source fields traceable.
Domain note 016: When changing calendar logic, add regression cases around boundary dates.
Domain note 017: When a rule system has variants, name the selected convention.
Domain note 018: When a result depends on unknown time, surface that limitation.
Domain note 019: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 020: When adding a new score, document its scale and interpretation.
Domain note 021: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 022: When adding fixtures, make input data and expected output easy to audit.
Domain note 023: When deriving a report from multiple engines, keep source fields traceable.
Domain note 024: When changing calendar logic, add regression cases around boundary dates.
Domain note 025: When a rule system has variants, name the selected convention.
Domain note 026: When a result depends on unknown time, surface that limitation.
Domain note 027: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 028: When adding a new score, document its scale and interpretation.
Domain note 029: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 030: When adding fixtures, make input data and expected output easy to audit.
Domain note 031: When deriving a report from multiple engines, keep source fields traceable.
Domain note 032: When changing calendar logic, add regression cases around boundary dates.
Domain note 033: When a rule system has variants, name the selected convention.
Domain note 034: When a result depends on unknown time, surface that limitation.
Domain note 035: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 036: When adding a new score, document its scale and interpretation.
Domain note 037: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 038: When adding fixtures, make input data and expected output easy to audit.
Domain note 039: When deriving a report from multiple engines, keep source fields traceable.
Domain note 040: When changing calendar logic, add regression cases around boundary dates.
Domain note 041: When a rule system has variants, name the selected convention.
Domain note 042: When a result depends on unknown time, surface that limitation.
Domain note 043: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 044: When adding a new score, document its scale and interpretation.
Domain note 045: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 046: When adding fixtures, make input data and expected output easy to audit.
Domain note 047: When deriving a report from multiple engines, keep source fields traceable.
Domain note 048: When changing calendar logic, add regression cases around boundary dates.
Domain note 049: When a rule system has variants, name the selected convention.
Domain note 050: When a result depends on unknown time, surface that limitation.
Domain note 051: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 052: When adding a new score, document its scale and interpretation.
Domain note 053: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 054: When adding fixtures, make input data and expected output easy to audit.
Domain note 055: When deriving a report from multiple engines, keep source fields traceable.
Domain note 056: When changing calendar logic, add regression cases around boundary dates.
Domain note 057: When a rule system has variants, name the selected convention.
Domain note 058: When a result depends on unknown time, surface that limitation.
Domain note 059: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 060: When adding a new score, document its scale and interpretation.
Domain note 061: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 062: When adding fixtures, make input data and expected output easy to audit.
Domain note 063: When deriving a report from multiple engines, keep source fields traceable.
Domain note 064: When changing calendar logic, add regression cases around boundary dates.
Domain note 065: When a rule system has variants, name the selected convention.
Domain note 066: When a result depends on unknown time, surface that limitation.
Domain note 067: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 068: When adding a new score, document its scale and interpretation.
Domain note 069: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 070: When adding fixtures, make input data and expected output easy to audit.
Domain note 071: When deriving a report from multiple engines, keep source fields traceable.
Domain note 072: When changing calendar logic, add regression cases around boundary dates.
Domain note 073: When a rule system has variants, name the selected convention.
Domain note 074: When a result depends on unknown time, surface that limitation.
Domain note 075: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 076: When adding a new score, document its scale and interpretation.
Domain note 077: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 078: When adding fixtures, make input data and expected output easy to audit.
Domain note 079: When deriving a report from multiple engines, keep source fields traceable.
Domain note 080: When changing calendar logic, add regression cases around boundary dates.
Domain note 081: When a rule system has variants, name the selected convention.
Domain note 082: When a result depends on unknown time, surface that limitation.
Domain note 083: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 084: When adding a new score, document its scale and interpretation.
Domain note 085: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 086: When adding fixtures, make input data and expected output easy to audit.
Domain note 087: When deriving a report from multiple engines, keep source fields traceable.
Domain note 088: When changing calendar logic, add regression cases around boundary dates.
Domain note 089: When a rule system has variants, name the selected convention.
Domain note 090: When a result depends on unknown time, surface that limitation.
Domain note 091: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 092: When adding a new score, document its scale and interpretation.
Domain note 093: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 094: When adding fixtures, make input data and expected output easy to audit.
Domain note 095: When deriving a report from multiple engines, keep source fields traceable.
Domain note 096: When changing calendar logic, add regression cases around boundary dates.
Domain note 097: When a rule system has variants, name the selected convention.
Domain note 098: When a result depends on unknown time, surface that limitation.
Domain note 099: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 100: When adding a new score, document its scale and interpretation.
Domain note 101: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 102: When adding fixtures, make input data and expected output easy to audit.
Domain note 103: When deriving a report from multiple engines, keep source fields traceable.
Domain note 104: When changing calendar logic, add regression cases around boundary dates.
Domain note 105: When a rule system has variants, name the selected convention.
Domain note 106: When a result depends on unknown time, surface that limitation.
Domain note 107: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 108: When adding a new score, document its scale and interpretation.
Domain note 109: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 110: When adding fixtures, make input data and expected output easy to audit.
Domain note 111: When deriving a report from multiple engines, keep source fields traceable.
Domain note 112: When changing calendar logic, add regression cases around boundary dates.
Domain note 113: When a rule system has variants, name the selected convention.
Domain note 114: When a result depends on unknown time, surface that limitation.
Domain note 115: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 116: When adding a new score, document its scale and interpretation.
Domain note 117: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 118: When adding fixtures, make input data and expected output easy to audit.
Domain note 119: When deriving a report from multiple engines, keep source fields traceable.
Domain note 120: When changing calendar logic, add regression cases around boundary dates.
Domain note 121: When a rule system has variants, name the selected convention.
Domain note 122: When a result depends on unknown time, surface that limitation.
Domain note 123: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 124: When adding a new score, document its scale and interpretation.
Domain note 125: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 126: When adding fixtures, make input data and expected output easy to audit.
Domain note 127: When deriving a report from multiple engines, keep source fields traceable.
Domain note 128: When changing calendar logic, add regression cases around boundary dates.
Domain note 129: When a rule system has variants, name the selected convention.
Domain note 130: When a result depends on unknown time, surface that limitation.
Domain note 131: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 132: When adding a new score, document its scale and interpretation.
Domain note 133: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 134: When adding fixtures, make input data and expected output easy to audit.
Domain note 135: When deriving a report from multiple engines, keep source fields traceable.
Domain note 136: When changing calendar logic, add regression cases around boundary dates.
Domain note 137: When a rule system has variants, name the selected convention.
Domain note 138: When a result depends on unknown time, surface that limitation.
Domain note 139: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 140: When adding a new score, document its scale and interpretation.
Domain note 141: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 142: When adding fixtures, make input data and expected output easy to audit.
Domain note 143: When deriving a report from multiple engines, keep source fields traceable.
Domain note 144: When changing calendar logic, add regression cases around boundary dates.
Domain note 145: When a rule system has variants, name the selected convention.
Domain note 146: When a result depends on unknown time, surface that limitation.
Domain note 147: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 148: When adding a new score, document its scale and interpretation.
Domain note 149: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 150: When adding fixtures, make input data and expected output easy to audit.
Domain note 151: When deriving a report from multiple engines, keep source fields traceable.
Domain note 152: When changing calendar logic, add regression cases around boundary dates.
Domain note 153: When a rule system has variants, name the selected convention.
Domain note 154: When a result depends on unknown time, surface that limitation.
Domain note 155: When location affects calculations, preserve coordinates and timezone in metadata.
Domain note 156: When adding a new score, document its scale and interpretation.
Domain note 157: When comparing systems, avoid implying they measure the same thing unless the code explicitly maps them.
Domain note 158: When adding fixtures, make input data and expected output easy to audit.
Domain note 159: When deriving a report from multiple engines, keep source fields traceable.
Domain note 160: When changing calendar logic, add regression cases around boundary dates.

Appendix F - Release Notes Template

## Release YYYY-MM-DD

### Changed
- Describe user-visible changes.

### Fixed
- Describe bug fixes with affected crates.

### Validation
- List commands that passed.

### Notes
- Mention known limitations or follow-up work.

Release note 001: keep release text factual, scoped, and tied to validation evidence.
Release note 002: keep release text factual, scoped, and tied to validation evidence.
Release note 003: keep release text factual, scoped, and tied to validation evidence.
Release note 004: keep release text factual, scoped, and tied to validation evidence.
Release note 005: keep release text factual, scoped, and tied to validation evidence.
Release note 006: keep release text factual, scoped, and tied to validation evidence.
Release note 007: keep release text factual, scoped, and tied to validation evidence.
Release note 008: keep release text factual, scoped, and tied to validation evidence.
Release note 009: keep release text factual, scoped, and tied to validation evidence.
Release note 010: keep release text factual, scoped, and tied to validation evidence.
Release note 011: keep release text factual, scoped, and tied to validation evidence.
Release note 012: keep release text factual, scoped, and tied to validation evidence.
Release note 013: keep release text factual, scoped, and tied to validation evidence.
Release note 014: keep release text factual, scoped, and tied to validation evidence.
Release note 015: keep release text factual, scoped, and tied to validation evidence.
Release note 016: keep release text factual, scoped, and tied to validation evidence.
Release note 017: keep release text factual, scoped, and tied to validation evidence.
Release note 018: keep release text factual, scoped, and tied to validation evidence.
Release note 019: keep release text factual, scoped, and tied to validation evidence.
Release note 020: keep release text factual, scoped, and tied to validation evidence.
Release note 021: keep release text factual, scoped, and tied to validation evidence.
Release note 022: keep release text factual, scoped, and tied to validation evidence.
Release note 023: keep release text factual, scoped, and tied to validation evidence.
Release note 024: keep release text factual, scoped, and tied to validation evidence.
Release note 025: keep release text factual, scoped, and tied to validation evidence.
Release note 026: keep release text factual, scoped, and tied to validation evidence.
Release note 027: keep release text factual, scoped, and tied to validation evidence.
Release note 028: keep release text factual, scoped, and tied to validation evidence.
Release note 029: keep release text factual, scoped, and tied to validation evidence.
Release note 030: keep release text factual, scoped, and tied to validation evidence.
Release note 031: keep release text factual, scoped, and tied to validation evidence.
Release note 032: keep release text factual, scoped, and tied to validation evidence.
Release note 033: keep release text factual, scoped, and tied to validation evidence.
Release note 034: keep release text factual, scoped, and tied to validation evidence.
Release note 035: keep release text factual, scoped, and tied to validation evidence.
Release note 036: keep release text factual, scoped, and tied to validation evidence.
Release note 037: keep release text factual, scoped, and tied to validation evidence.
Release note 038: keep release text factual, scoped, and tied to validation evidence.
Release note 039: keep release text factual, scoped, and tied to validation evidence.
Release note 040: keep release text factual, scoped, and tied to validation evidence.
Release note 041: keep release text factual, scoped, and tied to validation evidence.
Release note 042: keep release text factual, scoped, and tied to validation evidence.
Release note 043: keep release text factual, scoped, and tied to validation evidence.
Release note 044: keep release text factual, scoped, and tied to validation evidence.
Release note 045: keep release text factual, scoped, and tied to validation evidence.
Release note 046: keep release text factual, scoped, and tied to validation evidence.
Release note 047: keep release text factual, scoped, and tied to validation evidence.
Release note 048: keep release text factual, scoped, and tied to validation evidence.
Release note 049: keep release text factual, scoped, and tied to validation evidence.
Release note 050: keep release text factual, scoped, and tied to validation evidence.
Release note 051: keep release text factual, scoped, and tied to validation evidence.
Release note 052: keep release text factual, scoped, and tied to validation evidence.
Release note 053: keep release text factual, scoped, and tied to validation evidence.
Release note 054: keep release text factual, scoped, and tied to validation evidence.
Release note 055: keep release text factual, scoped, and tied to validation evidence.
Release note 056: keep release text factual, scoped, and tied to validation evidence.
Release note 057: keep release text factual, scoped, and tied to validation evidence.
Release note 058: keep release text factual, scoped, and tied to validation evidence.
Release note 059: keep release text factual, scoped, and tied to validation evidence.
Release note 060: keep release text factual, scoped, and tied to validation evidence.
Release note 061: keep release text factual, scoped, and tied to validation evidence.
Release note 062: keep release text factual, scoped, and tied to validation evidence.
Release note 063: keep release text factual, scoped, and tied to validation evidence.
Release note 064: keep release text factual, scoped, and tied to validation evidence.
Release note 065: keep release text factual, scoped, and tied to validation evidence.
Release note 066: keep release text factual, scoped, and tied to validation evidence.
Release note 067: keep release text factual, scoped, and tied to validation evidence.
Release note 068: keep release text factual, scoped, and tied to validation evidence.
Release note 069: keep release text factual, scoped, and tied to validation evidence.
Release note 070: keep release text factual, scoped, and tied to validation evidence.
Release note 071: keep release text factual, scoped, and tied to validation evidence.
Release note 072: keep release text factual, scoped, and tied to validation evidence.
Release note 073: keep release text factual, scoped, and tied to validation evidence.
Release note 074: keep release text factual, scoped, and tied to validation evidence.
Release note 075: keep release text factual, scoped, and tied to validation evidence.
Release note 076: keep release text factual, scoped, and tied to validation evidence.
Release note 077: keep release text factual, scoped, and tied to validation evidence.
Release note 078: keep release text factual, scoped, and tied to validation evidence.
Release note 079: keep release text factual, scoped, and tied to validation evidence.
Release note 080: keep release text factual, scoped, and tied to validation evidence.

Appendix G - Troubleshooting

Symptom	Check
Dioxus command cannot find config	Run it from `crates/eon-ui`.
Wasm target missing	Run `rustup target add wasm32-unknown-unknown`.
CI build differs from local build	Compare local commands with `.github/workflows/ci.yml` and `.github/workflows/deploy.yml`.
UI freezes during analysis	Check for synchronous façade calls inside component render paths.
Unknown-time behavior looks inconsistent	Inspect DTO constructor use and `BirthTimePrecision` mapping.
Tailwind output missing in deploy artifact	Check the post-build Tailwind generation step in `deploy.yml`.
Unexpected npm failure	The active frontend does not use npm scripts; use Cargo and Dioxus commands.

Troubleshooting note 001: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 002: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 003: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 004: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 005: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 006: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 007: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 008: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 009: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 010: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 011: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 012: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 013: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 014: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 015: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 016: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 017: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 018: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 019: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 020: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 021: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 022: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 023: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 024: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 025: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 026: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 027: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 028: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 029: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 030: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 031: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 032: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 033: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 034: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 035: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 036: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 037: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 038: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 039: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 040: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 041: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 042: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 043: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 044: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 045: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 046: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 047: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 048: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 049: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 050: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 051: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 052: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 053: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 054: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 055: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 056: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 057: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 058: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 059: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 060: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 061: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 062: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 063: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 064: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 065: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 066: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 067: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 068: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 069: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 070: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 071: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 072: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 073: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 074: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 075: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 076: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 077: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 078: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 079: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 080: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 081: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 082: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 083: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 084: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 085: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 086: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 087: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 088: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 089: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 090: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 091: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 092: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 093: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 094: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 095: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 096: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 097: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 098: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 099: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.
Troubleshooting note 100: reproduce with the smallest command that exercises the failing layer, then widen only after the focused check passes.

Appendix H - File Ownership Guide

Concern	Likely owner
Birth form behavior	`crates/eon-ui/src/components/shared` and `crates/eon-ui/src/store/mod.rs`
Global UI state	`crates/eon-ui/src/store/mod.rs`
Saju calculation	`crates/eon-saju` and `crates/eon-service/src/services/saju.rs`
Vedic calculation	`crates/eon-vedic` and `crates/eon-service/src/services/vedic.rs`
ZWDS calculation	`crates/eon-zwds` and `crates/eon-service/src/services/zwds.rs`
Western calculation	`crates/eon-western` and `crates/eon-service/src/services/western.rs`
Human Design calculation	`crates/eon-human-design` and `crates/eon-service/src/services/human_design.rs`
Qimen calculation	`crates/eon-qimen` and `crates/eon-service/src/services/qimen.rs`
Deployment	`.github/workflows/deploy.yml` and `crates/eon-ui/public/vercel.json`
Workspace metadata	`Cargo.toml` and `Cargo.lock`

Ownership note 001: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 002: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 003: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 004: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 005: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 006: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 007: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 008: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 009: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 010: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 011: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 012: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 013: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 014: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 015: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 016: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 017: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 018: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 019: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 020: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 021: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 022: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 023: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 024: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 025: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 026: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 027: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 028: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 029: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 030: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 031: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 032: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 033: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 034: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 035: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 036: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 037: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 038: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 039: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 040: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 041: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 042: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 043: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 044: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 045: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 046: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 047: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 048: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 049: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 050: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 051: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 052: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 053: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 054: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 055: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 056: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 057: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 058: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 059: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 060: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 061: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 062: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 063: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 064: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 065: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 066: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 067: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 068: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 069: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 070: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 071: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 072: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 073: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 074: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 075: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 076: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 077: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 078: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 079: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 080: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 081: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 082: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 083: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 084: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 085: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 086: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 087: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 088: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 089: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 090: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 091: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 092: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 093: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 094: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 095: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 096: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 097: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 098: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 099: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.
Ownership note 100: start at the owner file, then follow imports outward only when the local owner cannot explain the behavior.

Appendix I - Review Checklist

Review item 001: Does the change preserve the service boundary?
Review item 002: Does the UI still use AnalysisState?
Review item 003: Are DTO constructors used correctly?
Review item 004: Is async work outside the render path?
Review item 005: Are tests scoped to the changed behavior?
Review item 006: Is wording factual and not overpromising?
Review item 007: Are CI commands still accurate?
Review item 008: Are generated assets intentional?
Review item 009: Are calendar and timezone assumptions explicit?
Review item 010: Is the commit limited to related changes?
Review item 011: Does the change preserve the service boundary?
Review item 012: Does the UI still use AnalysisState?
Review item 013: Are DTO constructors used correctly?
Review item 014: Is async work outside the render path?
Review item 015: Are tests scoped to the changed behavior?
Review item 016: Is wording factual and not overpromising?
Review item 017: Are CI commands still accurate?
Review item 018: Are generated assets intentional?
Review item 019: Are calendar and timezone assumptions explicit?
Review item 020: Is the commit limited to related changes?
Review item 021: Does the change preserve the service boundary?
Review item 022: Does the UI still use AnalysisState?
Review item 023: Are DTO constructors used correctly?
Review item 024: Is async work outside the render path?
Review item 025: Are tests scoped to the changed behavior?
Review item 026: Is wording factual and not overpromising?
Review item 027: Are CI commands still accurate?
Review item 028: Are generated assets intentional?
Review item 029: Are calendar and timezone assumptions explicit?
Review item 030: Is the commit limited to related changes?
Review item 031: Does the change preserve the service boundary?
Review item 032: Does the UI still use AnalysisState?
Review item 033: Are DTO constructors used correctly?
Review item 034: Is async work outside the render path?
Review item 035: Are tests scoped to the changed behavior?
Review item 036: Is wording factual and not overpromising?
Review item 037: Are CI commands still accurate?
Review item 038: Are generated assets intentional?
Review item 039: Are calendar and timezone assumptions explicit?
Review item 040: Is the commit limited to related changes?
Review item 041: Does the change preserve the service boundary?
Review item 042: Does the UI still use AnalysisState?
Review item 043: Are DTO constructors used correctly?
Review item 044: Is async work outside the render path?
Review item 045: Are tests scoped to the changed behavior?
Review item 046: Is wording factual and not overpromising?
Review item 047: Are CI commands still accurate?
Review item 048: Are generated assets intentional?
Review item 049: Are calendar and timezone assumptions explicit?
Review item 050: Is the commit limited to related changes?
Review item 051: Does the change preserve the service boundary?
Review item 052: Does the UI still use AnalysisState?
Review item 053: Are DTO constructors used correctly?
Review item 054: Is async work outside the render path?
Review item 055: Are tests scoped to the changed behavior?
Review item 056: Is wording factual and not overpromising?
Review item 057: Are CI commands still accurate?
Review item 058: Are generated assets intentional?
Review item 059: Are calendar and timezone assumptions explicit?
Review item 060: Is the commit limited to related changes?
Review item 061: Does the change preserve the service boundary?
Review item 062: Does the UI still use AnalysisState?
Review item 063: Are DTO constructors used correctly?
Review item 064: Is async work outside the render path?
Review item 065: Are tests scoped to the changed behavior?
Review item 066: Is wording factual and not overpromising?
Review item 067: Are CI commands still accurate?
Review item 068: Are generated assets intentional?
Review item 069: Are calendar and timezone assumptions explicit?
Review item 070: Is the commit limited to related changes?
Review item 071: Does the change preserve the service boundary?
Review item 072: Does the UI still use AnalysisState?
Review item 073: Are DTO constructors used correctly?
Review item 074: Is async work outside the render path?
Review item 075: Are tests scoped to the changed behavior?
Review item 076: Is wording factual and not overpromising?
Review item 077: Are CI commands still accurate?
Review item 078: Are generated assets intentional?
Review item 079: Are calendar and timezone assumptions explicit?
Review item 080: Is the commit limited to related changes?
Review item 081: Does the change preserve the service boundary?
Review item 082: Does the UI still use AnalysisState?
Review item 083: Are DTO constructors used correctly?
Review item 084: Is async work outside the render path?
Review item 085: Are tests scoped to the changed behavior?
Review item 086: Is wording factual and not overpromising?
Review item 087: Are CI commands still accurate?
Review item 088: Are generated assets intentional?
Review item 089: Are calendar and timezone assumptions explicit?
Review item 090: Is the commit limited to related changes?
Review item 091: Does the change preserve the service boundary?
Review item 092: Does the UI still use AnalysisState?
Review item 093: Are DTO constructors used correctly?
Review item 094: Is async work outside the render path?
Review item 095: Are tests scoped to the changed behavior?
Review item 096: Is wording factual and not overpromising?
Review item 097: Are CI commands still accurate?
Review item 098: Are generated assets intentional?
Review item 099: Are calendar and timezone assumptions explicit?
Review item 100: Is the commit limited to related changes?
Review item 101: Does the change preserve the service boundary?
Review item 102: Does the UI still use AnalysisState?
Review item 103: Are DTO constructors used correctly?
Review item 104: Is async work outside the render path?
Review item 105: Are tests scoped to the changed behavior?
Review item 106: Is wording factual and not overpromising?
Review item 107: Are CI commands still accurate?
Review item 108: Are generated assets intentional?
Review item 109: Are calendar and timezone assumptions explicit?
Review item 110: Is the commit limited to related changes?
Review item 111: Does the change preserve the service boundary?
Review item 112: Does the UI still use AnalysisState?
Review item 113: Are DTO constructors used correctly?
Review item 114: Is async work outside the render path?
Review item 115: Are tests scoped to the changed behavior?
Review item 116: Is wording factual and not overpromising?
Review item 117: Are CI commands still accurate?
Review item 118: Are generated assets intentional?
Review item 119: Are calendar and timezone assumptions explicit?
Review item 120: Is the commit limited to related changes?
Review item 121: Does the change preserve the service boundary?
Review item 122: Does the UI still use AnalysisState?
Review item 123: Are DTO constructors used correctly?
Review item 124: Is async work outside the render path?
Review item 125: Are tests scoped to the changed behavior?
Review item 126: Is wording factual and not overpromising?
Review item 127: Are CI commands still accurate?
Review item 128: Are generated assets intentional?
Review item 129: Are calendar and timezone assumptions explicit?
Review item 130: Is the commit limited to related changes?
Review item 131: Does the change preserve the service boundary?
Review item 132: Does the UI still use AnalysisState?
Review item 133: Are DTO constructors used correctly?
Review item 134: Is async work outside the render path?
Review item 135: Are tests scoped to the changed behavior?
Review item 136: Is wording factual and not overpromising?
Review item 137: Are CI commands still accurate?
Review item 138: Are generated assets intentional?
Review item 139: Are calendar and timezone assumptions explicit?
Review item 140: Is the commit limited to related changes?
Review item 141: Does the change preserve the service boundary?
Review item 142: Does the UI still use AnalysisState?
Review item 143: Are DTO constructors used correctly?
Review item 144: Is async work outside the render path?
Review item 145: Are tests scoped to the changed behavior?
Review item 146: Is wording factual and not overpromising?
Review item 147: Are CI commands still accurate?
Review item 148: Are generated assets intentional?
Review item 149: Are calendar and timezone assumptions explicit?
Review item 150: Is the commit limited to related changes?

License

Workspace metadata declares the project license as MIT. A root LICENSE file is not present in the current tree. Add one if downstream tooling or distribution requires a standalone license document.

Documentation note 1815: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1816: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1817: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1818: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1819: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1820: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1821: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1822: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1823: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1824: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1825: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1826: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1827: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1828: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1829: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1830: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1831: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1832: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1833: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1834: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1835: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1836: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1837: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1838: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1839: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1840: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1841: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1842: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1843: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1844: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1845: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1846: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1847: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1848: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1849: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1850: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1851: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1852: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1853: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1854: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1855: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1856: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1857: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1858: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1859: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1860: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1861: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1862: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1863: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1864: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1865: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1866: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1867: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1868: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1869: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1870: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1871: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1872: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1873: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1874: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1875: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1876: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1877: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1878: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1879: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1880: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1881: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1882: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1883: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1884: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1885: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1886: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1887: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1888: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1889: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1890: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1891: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1892: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1893: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1894: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1895: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1896: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1897: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1898: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1899: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1900: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1901: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1902: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1903: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1904: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1905: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1906: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1907: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1908: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1909: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1910: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1911: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1912: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1913: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1914: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1915: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1916: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1917: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1918: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1919: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1920: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1921: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1922: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1923: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1924: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1925: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1926: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1927: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1928: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1929: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1930: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1931: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1932: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1933: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1934: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1935: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1936: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1937: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1938: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1939: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1940: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1941: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1942: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1943: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1944: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1945: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1946: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1947: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1948: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1949: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1950: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1951: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1952: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1953: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1954: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1955: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1956: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1957: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1958: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1959: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1960: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1961: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1962: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1963: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1964: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1965: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1966: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1967: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1968: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1969: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1970: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1971: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1972: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1973: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1974: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1975: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1976: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1977: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1978: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1979: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1980: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1981: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1982: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1983: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1984: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1985: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1986: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1987: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1988: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1989: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1990: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1991: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1992: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1993: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1994: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.
Documentation note 1995: keep future README edits factual, implementation-grounded, and aligned with the Rust/Dioxus architecture.

Name		Name	Last commit message	Last commit date
Latest commit History 478 Commits
.agent/artifacts		.agent/artifacts
.agents		.agents
.cargo		.cargo
.github		.github
api		api
assets		assets
crates		crates
docs		docs
scripts		scripts
.env		.env
.gitignore		.gitignore
AGENTS.md		AGENTS.md
Cargo.lock		Cargo.lock
Cargo.toml		Cargo.toml
ORIGINAL_REQUEST.md		ORIGINAL_REQUEST.md
PROJECT.md		PROJECT.md
README.md		README.md
TEST_INFRA.md		TEST_INFRA.md
TEST_READY.md		TEST_READY.md
rust-toolchain.toml		rust-toolchain.toml
test-wasm.mjs		test-wasm.mjs
vercel.json		vercel.json

Folders and files

Latest commit

History

Repository files navigation

Eon

Table of Contents