History

Tianyi Cui 066f94c7e0 docs: unwrap hard-wrapped Markdown to one line per paragraph Hard line breaks mid-paragraph make docs harder to edit and diff — a one-word change reflows and re-diffs the whole paragraph. Reflow all tracked non-vendor Markdown (plus vendor/AGENTS.md) so each prose paragraph is a single line; soft-wrapping is the editor's job. Fenced code, tables, and list structure are preserved (wrapped list items fold to one line per bullet). Documents the convention in AGENTS.md.		2026-06-13 20:27:04 +08:00
..
001-property-based-testing.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
002-mutation-testing.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
003-deterministic-and-stress-testing.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
004-architectural-conformance.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
005-runtime-validation-and-error-taxonomy.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
006-doc-sync-and-api-reports.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
007-supply-chain-and-vendor-drift.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
008-immutable-public-surfaces.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00
README.md	docs: unwrap hard-wrapped Markdown to one line per paragraph	2026-06-13 20:27:04 +08:00

README.md

RFCs

Proposals for substantial future work — reviewed before implementation, unlike ADRs (which record decisions already made). Each RFC groups a related set of ideas from the quality/robustness proposal (2026-06-11); statuses move proposed → accepted → implemented (then usually graduate to an ADR).

#	Title	Status
001	Property-based testing for protocol-shaped code	proposed
002	Mutation testing as the coverage counterweight	proposed
003	Deterministic tests + replay invariant fixture + race stress	proposed
004	Architectural rules: dependency-cruiser, adapter conformance kit	proposed
005	Runtime arg validation, structured error taxonomy, dev-mode invariants	proposed
006	Doc-sync enforcement and API extractor reports	proposed
007	Supply chain checks and vendor drift verification	proposed
008	Deep-readonly public surfaces	proposed