Reference
Contributing
This repository is building a production-grade document runtime. Contributions should protect correctness, fidelity, security, performance, and maintainability.
Generated from this repository's own design document:
CONTRIBUTING.md
This repository is building a production-grade document runtime. Contributions should protect correctness, fidelity, security, performance, and maintainability.
Development Contract
Before implementation:
- Read the relevant docs in
docs/. - Write or update the design note for the work.
- Discuss and finalize the approach.
- Add or update the tracker item in
docs/14-EXECUTION-TRACKER.md. - Identify required tests, compatibility impact, and CI gates.
During implementation:
- Keep changes narrowly scoped.
- Prefer existing architecture and documented module boundaries.
- Add focused tests with each behavior change.
- Update docs when behavior, public API, compatibility, or process changes.
- Avoid silent data loss, implicit network access, and unbounded parsing.
Before merge:
- Run formatting, linting, type checks, and relevant tests.
- Confirm the tracker status is current.
- Update ADRs for architectural decisions.
- Document performance, security, and compatibility impact.
- Ensure CI is green.
Pull Request Requirements
Every PR should include:
- problem statement;
- design summary;
- tests run;
- compatibility impact;
- performance impact when relevant;
- security impact when parsing, input, file, font, image, plugin, or network behavior changes;
- public API impact;
- documentation changes;
- tracker link or item id;
- ADR link when applicable.
Quality Bar
The default expectation is production quality:
- deterministic behavior where specified;
- stable error handling;
- no panics across public API boundaries;
- no document content in normal logs;
- bounded parsing and resource limits;
- reproducible tests;
- fixtures for document compatibility work;
- visual and structural regression coverage for layout/rendering work.
Local Checks
The current foundation gate is:
cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
cargo test --workspace --all-features --locked
cargo test --doc --workspace --all-features --locked
cargo check --workspace --all-features --locked --target wasm32-unknown-unknown
cargo doc --workspace --all-features --no-deps --locked
The CI docs job runs the cargo doc step with RUSTDOCFLAGS="-D warnings", so every rustdoc lint is a hard failure. To reproduce it exactly:
RUSTDOCFLAGS="-D warnings" cargo doc --workspace --all-features --no-deps --locked
Rustdoc gotcha — private intra-doc links. A public doc comment that links a private type with intra-doc-link syntax (` [Type] ) emits a private_intra_doc_links warning, which -D warnings turns into a red CI docs job. This has bitten casual-doc-wasm twice on its private serde-serialization structs (e.g. ReviewCommentSummaryJson, A11yBlockJson). When a doc comment refers to a private/internal type, use a plain code span ( Type , no brackets) instead of an intra-doc link. Reserve [Type] ` for items that are public from the linking item's scope.
Dependency policy additionally uses:
cargo deny --locked check
cargo audit --deny warnings
Commit Style
Use short, factual commit messages. Conventional prefixes are preferred when useful:
docs:feat:fix:test:ci:refactor:perf:security:
License
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in OpenDoc is provided under the Apache License 2.0, without additional terms or conditions.