Forma 3.0 is one repository and seven coordinated packages. These links describe the shipped APIs. Historical decisions and release evidence are kept separately from the path an application author should follow.
Build with Forma#
| Need | Start here |
|---|---|
| Understand the rendering choices and tradeoffs | 3.0 architecture |
| Start a Rust + TypeScript app | Scaffolder and rendering modes |
| Build browser UI or a static site | Core quickstart and API |
| Use Rust request data in a page | Declared props and server API |
| Activate server-rendered islands | Islands and state |
| Use the explicit HTML runtime | HTML runtime |
| Know what compiles natively | Admitted subset and build diagnostics |
| Configure a build or deployment | Build package |
| Upgrade to 3.0 | Upgrade guide and compatibility |
| Diagnose a failure | Diagnostic catalogue |
Contracts and security#
- FMIR v3 format: binary envelope, sections and reader rules.
- Native/browser parity: names, values, markers and list keys.
- Response policy and Trusted Types: typed responses and raw-HTML trust boundaries.
- Ownership invariant: isolation and cleanup obligations.
- Security and support: reporting and supported release lines.
Contribute and verify#
Start with contributing and the testing policy. The cross-package tests, parity harness, performance protocol and native fuzzers explain the checks behind the contracts. The release guide describes maintainer procedures; it is not required to build an application.
Release status and history#
- 3.0 as-built summary: actual publication, qualification, completed post-release soak and remaining limits.
- Release records index: current procedures versus dated evidence.
- Repository/documentation layout: public documentation, internal work records and older repository maintenance.
- Historical architecture and archive: earlier designs and preserved evidence, not current API instructions.
- Deferred governance proposal: implementation and rollout are distinguished; the separate identity and external alerts are not enabled by documentation.
Document shipped behavior against code and tests. Attach measured claims to their actual version, producer and scope; a historical result is not a fresh run. Retain original evidence and failures. Keep operational handoffs and work boards outside the source tree; use public guides and reproducible records for users.