meta.book.rfd_changes

An RFD branch contains both the design record and the proposed normative Design changes. The RFD records motivation, alternatives, goals, and a high-level overview of the required changes, with links to the affected Design pages and anchors. Its implementation plan develops that overview into stages. Acceptance merges the record and specification changes together; unfinished implementation or tests remain explicit TODO entries. Subsequent implementation replaces those entries with code and evidence. Completing an RFD does not require copying its rules into Design, because the normative changes were already expressed there.

Read in specification context · design/meta/book.md

Implementation

TODO crates/sage-meta/tests/spec_plan.rs:252–259

sage_meta::todo · test:spec_plan

TODO: Verify RFD guidance/template links to the same-branch Design diff and records pending implementation without later rule promotion.

#![allow(unused)]
fn main() {
    // {anchor}`meta.book.rfd_changes`<<
    #[test]
    #[sage::test(meta.book.rfd_changes)]
    fn rfd_branches_include_the_design_changes() {
        // TODO: Verify RFD guidance/template links to the same-branch Design diff
        // and records pending implementation without later rule promotion.
    }
    // >>

}

See more source ↗

Tests and review

Indexed tests and the implementation-completeness and test-adequacy review; no test run is implied.

TODO sage_meta::todo::rfd_branches_include_the_design_changes

crates/sage-meta/tests/spec_plan.rs · test:spec_plan

#![allow(unused)]
fn main() {
#[test]
    #[sage::test(meta.book.rfd_changes)]
    fn rfd_branches_include_the_design_changes() {
        // TODO: Verify RFD guidance/template links to the same-branch Design diff
        // and records pending implementation without later rule promotion.
    }
}

See more source ↗

Review: Accepted · final_quality.

Reviewed the complete meta.book.rfd_changes claim and its entire associated evidence. Both implementation and test associations point to the explicit todo::rfd_branches_include_the_design_changes region in spec_plan.rs. The function contains no assertions, only its TODO; it must remain deferred and is not evidence that repository branches or acceptance operations satisfy the workflow. No ordinary or N/A entries are associated. No behavior tests were executed.

The claim requires an RFD branch to carry the record and proposed normative Design changes together; motivation, alternatives, goals and a linked high-level overview; a staged implementation plan; acceptance of record and specification together; explicit TODO evidence for unfinished code/tests; subsequent replacement by implementation/evidence; and no delayed copying of normative rules into Design on completion. The existing TODO calls for verifying guidance/template links to the same-branch Design diff and pending implementation without later rule promotion, which is an honest deferral of this lifecycle check.

I captured the RFD guidance, README template, implementation-plan template and maintaining-the-docs guidance. The RFD guide instructs opening one branch/PR with both the RFD and corresponding Design changes, locating testable requirements in Design, linking rationale and steps to affected pages/anchors, and doing implementation PRs after acceptance. The README template requests motivation, high-level changes, links to each normative change, rationale/alternatives and an implementation-plan pointer; its specification-change instructions say not to wait for implementation completion to write normative paragraphs. The plan template asks for independently mergeable stages with Design anchors and verification, and explicitly says the proposal already contains the normative diff while implementation replaces placeholders. The authoring guidance reinforces same-change specification/code/test/review updates and generated TODO evidence. These are documentary workflow components, not an automated assertion that every actual branch follows them.

Replacing the placeholder requires concrete validation of the guidance/template contract and a representative proposed-to-accepted-to-implemented change fixture: verify record/Design coexistence and direct page/anchor links; required motivation/goals/alternatives/overview and staged plan; retained TODO implementation/test entries while unfinished; and replacement with substantive evidence without a second normative-rule promotion. Branch/merge properties require an explicit repository-history or review-process check rather than inference from a passing empty Rust function. All requirements remain accounted for as explicitly deferred. No implementation-completeness or lifecycle-execution claim is made, and no source edit or additional requested edit is necessary for this review.

Browse meta anchors

116 anchors

Anchor Implementation Tests

meta (116) 102 Implemented24 TODO 103 Implemented36 TODO

meta.anchors (22) 22 Implemented 21 Implemented12 TODO

anchor_pages Implemented ImplementedTODO

Every specification anchor has a stable page identifying the rule and showing its definition, context, implementation entries, and tests/evidence. The page includes Rust excerpts and access to surrounding source, and exposes each entry’s placeholder status and explanation. Multiple sites remain individually inspectable rather than being reduced to a single coverage badge.

Symposiun AGentic Environment (SAGE)

meta.book.rfd_changes

Implementation

Tests and review