Backend contracts
Implementation contracts, generated coverage tables, and framework testing records.
- Android JNI bindings
How Day's Rust calls Java and Java calls Rust on Android: java_class! bindings, the startup check, and the R8 keep rules they generate.
- API style
Argument-clarity rules for the day API: when a builder takes a value, a closure, or a binding, how coupled configuration and items are spelled, and how names stay predictable.
- Coverage matrix
What each backend actually renders. A kind with no renderer draws a visible ⟨kind⟩ placeholder instead of failing, so these gaps are invisible in a…
- daybridge
Foreign-language implementations of a Rust API: how Swift, Kotlin, and ArkTS arms are declared, generated, and kept in parity.
- Dayscript recorder coverage
Every Event a Day app can receive, and the dayscript step the recorder writes for it (DESIGN.md §14.6). Derived from day-spec's Event enum and…
- Declared element IDs and dayscript coverage
Declare an element identity at the piece. No resource catalog or build script is involved.
- Focus backend contract
Focus backend contract: retained contributor discussion and its implementation boundaries.
- Grid layout contract
Grid layout contract: retained contributor discussion and its implementation boundaries.
- Native project migration
Day can generate native build projects while preserving app-owned sources and configuration. Keep a persistent host when its custom targets, build phases,…
- Standalone pieces
How new pieces plug in as ordinary crates — front-end, per-toolkit backends, native code — without changing day itself.
- Tests in the app
day test: #[day::test] cases that run inside a built Day app on a chosen toolkit, GUI and headless, the conformance app, the results they leave, and the mock harness that runs the same cases under cargo test.
- Toolkit duty matrix
Which backend implements which Toolkit duty (crates/day-spec/src/lib.rs). ✓ = the backend defines the method; · = it inherits the day-spec default (a…