meta.reviews.complete_test_set
One review covers one anchor’s claim and its complete set of associated tests. The input records every eligible test associated with that anchor in a deterministic order. Several tests may cover different parts of a claim; each test need not establish the whole claim independently.
Read in specification context · design/meta/reviews.md
Implementation
Implemented crates/sage-meta/src/review.rs:256–261
sage_meta::review · lib:sage_meta
#![allow(unused)] fn main() { // {anchor}`meta.reviews.complete_test_set` tests.sort(); tests.dedup(); for ((path, crate_name, target, rust_path), (_, _, contents)) in test_fragments { fragments.push(InputFragment { path, }
Tests and review
Indexed tests and the implementation-completeness and test-adequacy review; no test run is implied.
Implemented sage_meta::added_or_removed_associations_invalidate_unchanged_saved_fragments
crates/sage-meta/tests/review.rs · test:review
#![allow(unused)] fn main() { #[test] #[sage::test(meta.reviews.complete_test_set)] #[sage::test(meta.reviews.fragment_associations)] #[sage::test(meta.reviews.input_format)] #[sage::test(meta.reviews.review_diagnostics)] #[sage::test(meta.reviews.staleness)] fn added_or_removed_associations_invalidate_unchanged_saved_fragments() { let fixture = Fixture::new(); fixture.approve(); let original = fixture.input(); let second = "#[test] #[sage::test(demo.rule)] fn second() { assert_eq!(1 + 3, 4); }"; fixture.write("src/tests.rs", &format!("{TEST}\n{second}")); let error = sage_meta::check(&fixture.0) .ensure_valid() .unwrap_err() .to_string(); assert!(error.contains("demo.rule"), "{error}"); assert!(error.contains("test associations"), "{error}"); assert!(error.contains("sage-review-checklist/SKILL.md"), "{error}"); let current = fixture.start(); assert_eq!(current.tests.len(), 2); assert_eq!(current.tests, fixture.start().tests); assert_eq!( original.tests[0], *current .tests .iter() .find(|t| t.rust_path.ends_with("verifies_result")) .unwrap() ); review::record(&fixture.0, "demo.rule", &Fixture::report()).unwrap(); fixture.write("src/tests.rs", TEST); let error = sage_meta::check(&fixture.0) .ensure_valid() .unwrap_err() .to_string(); assert!(error.contains("demo.rule"), "{error}"); assert!(error.contains("test associations"), "{error}"); assert!(error.contains("sage-review-checklist/SKILL.md"), "{error}"); fixture.approve(); fixture.write("src/lib.rs", "#[sage::item(crate)] mod model {}\nmod behavior;\n#[cfg(test)] mod tests;\n// {anchor}`demo.rule`\nfn another_implementation() {}\n"); let error = sage_meta::check(&fixture.0) .ensure_valid() .unwrap_err() .to_string(); assert!(error.contains("demo.rule"), "{error}"); assert!(error.contains("implementation associations"), "{error}"); assert!(error.contains("sage-review-checklist/SKILL.md"), "{error}"); assert_eq!(fixture.start().implementations.len(), 2); } }
Review: Accepted · final_quality.
Reviewed the full meta.reviews.complete_test_set claim, the associated review.rs implementation, and the complete added_or_removed_associations_invalidate_unchanged_saved_fragments test. This is source inspection; no behavior tests were rerun, and central execution is separate.
inventory iterates one canonical anchor at a time and creates one ReviewInput containing that claim and every site in rust.tests for that name. Each eligible site's full function source is sliced from its recorded span, metadata is added to tests, and a semantic test fragment is keyed by file/crate/target/Rust path. Conflicting spans for one semantic identity cause an ambiguity error rather than silently selecting a test. tests.sort/dedup gives deterministic metadata order, while the BTreeMap gives deterministic fragment order and deduplicates repeated associations to the same test. Distinct tests and targets remain distinct. Captured CorrespondenceIndex::record_tests is the eligibility producer: module-level built-in test functions in enabled standard harness targets, excluding ignored/conditionally ignored tests; accepted references append to the per-anchor vector. Captured evidence::placeholder_status preserves ordinary/TODO/N/A classification without filtering tests out of the review.
One review record is stored for the anchor, not one required proof per individual test. The prompt asks the reviewer to assess all requirements across the supplied implementation/test fragments, and inventory imposes no requirement that each test independently establish the complete claim. input_errors compares the complete saved/current tests metadata and initial fragments, so association-set changes invalidate the review even if an existing test body remains unchanged. Captured shared check wiring reports these review failures through ensure_valid.
The associated test starts with an approved one-test fixture, adds a second independently named test, and requires an anchor-specific test-associations diagnostic with the review-skill guidance. It then asserts the fresh input contains two tests, repeated starts yield identical ordered metadata, and the original test record remains exactly present. After recording the new set, removing the second test must again fail with the same association reason. The final implementation-association portion separately confirms adding a second implementation also invalidates the saved review and yields two current implementation entries; this supports the broader association regression without substituting for the explicit test-set assertions. Captured Fixture/TEST helpers create a real Cargo and Design workspace, call review::start/record and deserialize saved input; the key assertions are visible in the annotated body.
The implementation and test account for per-anchor scope, inclusion of the complete eligible set, deterministic ordering, association changes and collective rather than per-test claim coverage. There are no associated TODO or N/A entries. No concrete defect or additional necessary edit was found. No source changes are requested.
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. | ||||||||||||||
book_explorer | Implemented | ImplementedTODO | ||||||||||||
The book build includes the architecture explorer and its model and Rust
source snapshots. An explorer chapter embeds the browser and offers a full-page
view. The handwritten Crates landing page links to | ||||||||||||||
canonical_sources | Implemented | ImplementedTODO | ||||||||||||
A specification rule can be defined in a Markdown or | ||||||||||||||
| meta.anchors.content (7) | 7 Implemented | 7 Implemented | ||||||||||||
blocks | Implemented | Implemented | ||||||||||||
An anchor’s content starts after its definition marker and includes every subsequent Markdown block until the first applicable closing boundary. Blank lines do not end the content: paragraphs, lists, tables, and code blocks within that extent belong to the same anchor. | ||||||||||||||
explicit_end | Implemented | Implemented | ||||||||||||
A standalone line containing exactly | ||||||||||||||
heading | Implemented | Implemented | ||||||||||||
A Markdown section heading ends the active anchor’s content immediately before the heading, regardless of heading level. Both hash-prefixed and underline-style headings are boundaries. Prose following the heading remains outside an anchor until another definition begins. | ||||||||||||||
literal_syntax | Implemented | Implemented | ||||||||||||
Boundary-looking text inside fenced or indented code blocks, inline code, or escaped text does not open or close an anchor. Raw HTML examples do not supply anchor definitions, section headings, or end markers. A standalone end comment acts as a boundary only outside these literal contexts and enclosing HTML blocks. | ||||||||||||||
next_anchor | Implemented | Implemented | ||||||||||||
A new anchor definition ends the preceding anchor’s content immediately before the new marker. The new definition belongs to its own anchor; content extents do not overlap. | ||||||||||||||
source_end | Implemented | Implemented | ||||||||||||
An anchor’s content ends at the end of its containing Markdown document or
| ||||||||||||||
unmatched_end | Implemented | Implemented | ||||||||||||
An explicit end marker with no active anchor is a validation error. Another end marker after an explicit or implicit end, without an intervening definition, is therefore also an error. An anchor ending at another definition, a heading, or its source boundary does not require an explicit end marker. | ||||||||||||||
context_navigation | Implemented | ImplementedTODO | ||||||||||||
Clicking an anchor badge opens its anchor page. The page’s context link returns
to the defining Markdown paragraph or | ||||||||||||||
evidence_status | Implemented | ImplementedTODO | ||||||||||||
An implementation or test entry establishes a declared association, not proof that the rule is satisfied. Source inventories retain cfg conditions without claiming that a site was compiled or a test executed. Anchor pages distinguish test source, recorded run results, and other evidence such as traces. A passing structural check or a passing dummy test must not present a TODO or Not applicable entry as established behavioral evidence. | ||||||||||||||
explorer_navigation | Implemented | TODO | ||||||||||||
The explorer’s selected Sage entity or specification anchor is reflected in the enclosing chapter’s URL. Opening that URL restores the selection, and browser back/forward navigation keeps the chapter and explorer in agreement. Sharing a selection preserves the book’s navigation as well as the selected context. Every entity is directly addressable under the entity-link rule; these links are also available to references from other documentation. | ||||||||||||||
implementation_coverage | Implemented | ImplementedTODO | ||||||||||||
Every specification anchor has at least one explicitly declared Rust
implementation entry. An anchor without one is an error. A test annotation or
| ||||||||||||||
implementation_references | Implemented | ImplementedTODO | ||||||||||||
A Rust implementation entry is introduced by a
<code>// {anchor}`meta.language.calls.declared`</code> comment, optionally followed
immediately by | ||||||||||||||
placeholder_status | Implemented | ImplementedTODO | ||||||||||||
Implementation references and test annotations inside a Rust module named
The example’s | ||||||||||||||
point_excerpts | Implemented | ImplementedTODO | ||||||||||||
A point reference has no
| ||||||||||||||
region_balance | Implemented | Implemented | ||||||||||||
A region opener without a closing delimiter, or a closing delimiter without an open region, is an error. Delimiters in string literals do not open or close regions. Region boundaries are determined from source comments, independently of the five-line previews used for point references. The existing | ||||||||||||||
region_excerpts | Implemented | ImplementedTODO | ||||||||||||
A reference ending in
| ||||||||||||||
test_coverage | Implemented | Implemented | ||||||||||||
Every specification anchor must have at least one annotated Rust test. An anchor without a test is an error, independently of its implementation coverage. A placeholder test counts as an entry with its explicit status; an implementation placeholder alone cannot satisfy the test requirement. | ||||||||||||||
test_references | Implemented | Implemented | ||||||||||||
Every One test can cover several rules and a rule can have several tests. Unlike
| ||||||||||||||
unique_names | Implemented | ImplementedTODO | ||||||||||||
Every specification anchor has a well-formed full name and exactly one definition in the Design chapter inventory. Malformed markers and duplicate full names are errors. Names are derived from the defining chapter; moves between chapter namespaces rename the rule and require updating its references. Resolved names are dot-separated ASCII identifiers and describe independently
testable behavior. A Markdown definition uses a chapter-local name with the
custom MyST-style inline-role syntax. For example, in
The marker and the opening prose form one paragraph: do not leave a blank
line between them. Later blocks can continue the same claim under the
content rules. The example resolves to
| ||||||||||||||
| meta.book (21) | 10 Implemented18 TODO | 12 Implemented18 TODO | ||||||||||||
anchor_moves | ImplementedTODO | ImplementedTODO | ||||||||||||
Moving a rule within its chapter preserves its identity. Changing its local name or moving it into a different chapter namespace renames the rule and requires updating specification, implementation, and test references. Published links to the old location retain a redirect or context alias. A compatibility link does not create a second canonical definition or satisfy a stale code reference. | ||||||||||||||
authority | ImplementedTODO | ImplementedTODO | ||||||||||||
The mdBook Design chapter tree is the canonical specification. Markdown and
| ||||||||||||||
browser_delivery | TODO | ImplementedTODO | ||||||||||||
Book generation, standalone export, and local serving use the same resolved model and renderer to implement these browsing rules. Invalid models produce diagnostics instead of a partially valid explorer. A generated book or standalone HTML artifact includes the data and assets needed for navigation, search, entity links, and Rust source display without a Sage server. Each view identifies itself as a snapshot. Model or Rust edits become visible when that snapshot is rebuilt, exported again, or regenerated by restarting the server. | ||||||||||||||
browser_dependencies | TODO | TODO | ||||||||||||
Method views render each declared envelope clause with its effect kind and target: invocations, input reads, context creation, and transitive prohibitions. They expose possible direct callees, reverse callers, and overriding implementations, using the validator’s conservative dispatch resolution. Inherited prohibitions retain their declaring method. Linked targets lead to the corresponding entities. These views label declared permissions and prohibitions as such; they do not imply that a permitted call happened or that runtime conformance has been established. | ||||||||||||||
browser_rust_source | TODO | TODO | ||||||||||||
Readers can reveal or hide a Rust source pane without leaving the selected Sage entity. The pane follows selection and uses indexed Rust correspondences, showing the file, line numbers, and highlighted declaration with surrounding source. Multiple mapped sites are individually selectable. Missing source is reported explicitly. Module markers, macro-input sites, and cfg conditions remain distinguishable from a confirmed active executable implementation. The pane identifies its contents as a source snapshot; navigating to code does not establish that the code executed or satisfied a specification rule. | ||||||||||||||
browser_search | TODO | TODO | ||||||||||||
Search finds declared entities by name, qualified model path, descriptive prose, and corresponding Rust paths when available. Crate and entity-kind filters combine with the search text. Results identify each entity’s kind and owner and link directly to it, including named members. The view states when no entities match. Changing search or filters does not invalidate an entity’s direct link or prevent opening a linked entity outside the current results. | ||||||||||||||
browser_serve | TODO | TODO | ||||||||||||
The For example, | ||||||||||||||
browser_structure | TODO | TODO | ||||||||||||
Readers can navigate from crates to modules, declarations, and their members, with the owning crate, module, and declaration visible at each level. Crate views show purpose and dependencies. Declaration views show kind, descriptive prose, generic parameters, and the modeled structure: struct fields, enum variants and their fields, or the description of an opaque type. Class and context views show fields, base classes, and methods, distinguishing declared, inherited, abstract, and overriding methods. Method views show query/function kind, signature, and prose. References to modeled types, bases, and methods link to their declarations. | ||||||||||||||
chapter_names | ImplementedTODO | ImplementedTODO | ||||||||||||
An anchor’s full name combines its chapter namespace with the local name
written at its definition. The namespace is derived from the chapter source
path relative to Design, removing the extension and joining path components
with dots. For example, local The intended Markdown source spelling is local:
Rust references use the resolved full name, such as
| ||||||||||||||
crate_ownership | Implemented | Implemented | ||||||||||||
Every | ||||||||||||||
crates_landing | Implemented | Implemented | ||||||||||||
The Crates landing page preserves handwritten Markdown from
| ||||||||||||||
entity_links | TODO | TODO | ||||||||||||
Every declared Sage entity has an unambiguous direct link, including crates,
modules, types, classes, contexts, methods/queries, and named members such as
fields and enum variants. Opening a link selects the declaration or member in
its rendered context without a prior search or browser session. Links resolve
through the entity’s identity and owning scope: equal local names in different
owners remain distinct, and relocating a chapter does not break links to
unchanged model entities. Markdown and Entity links and specification anchors have different purposes. For example,
| ||||||||||||||
index_groups | ImplementedTODO | ImplementedTODO | ||||||||||||
The anchor index groups entries hierarchically by their name prefixes, such as
| ||||||||||||||
index_namespace_pages | Implemented | Implemented | ||||||||||||
The generated Anchors landing page lists every active rule. Each namespace
prefix has a page with the same table restricted to that prefix. A rule named
| ||||||||||||||
index_rows | ImplementedTODO | ImplementedTODO | ||||||||||||
The Design section includes an automatically generated index of every active anchor. Each anchor has a main row containing the final component of its name, with the namespace supplied by the enclosing group or page heading, and separate implementation and test statuses. The name’s tooltip shows its full identity. A disclosure control opens a second row containing its rendered specification text. Hiding the text preserves the main row. The linked name opens that anchor’s own page, independently of expanding or collapsing the text. | ||||||||||||||
index_status | ImplementedTODO | ImplementedTODO | ||||||||||||
Implementation and test status are computed independently from their declared
entries: ordinary entries display Implemented, | ||||||||||||||
rfd_changes | TODO | TODO | ||||||||||||
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. | ||||||||||||||
sage_chapters | TODO | ImplementedTODO | ||||||||||||
| ||||||||||||||
self_description | TODO | TODO | ||||||||||||
The specification-book system is itself specified by anchors in Design. Its rules participate in the same naming, reference validation, implementation and test coverage, status reporting, index, and anchor-page generation as all other rules. A rule about the validator or renderer receives no exemption from those requirements; unfinished work uses explicit TODO entries. | ||||||||||||||
shared_model | ImplementedTODO | ImplementedTODO | ||||||||||||
Book generation and | ||||||||||||||
source_roles | TODO | TODO | ||||||||||||
The Design overview contains Meta, Tenets, Anchors, Crates, and RFDs. Meta specifies the specification system itself. Tenets explains design principles without defining specification anchors. Anchors is generated from all active specification rules. Crates combines a handwritten reading map and modeled crate chapters. RFDs record changes and reasoning without defining active rules. The User’s Guide provides non-normative usage instructions. | ||||||||||||||
| meta.contracts (4) | 4 Implemented3 TODO | 4 Implemented3 TODO | ||||||||||||
cache_invocations | ImplementedTODO | ImplementedTODO | ||||||||||||
Every annotated source invocation is checked, including query cache hits and same-operation recursion. A Salsa request and its execution represent one architectural invocation. Internal validation, dependency reexecution, and accumulator traversal remain distinguishable from source requests; reexecution establishes the executing operation’s context without attributing its work to the suspended caller or inventing a source call. Verification covers cold, reused, validated, invalidated/reexecuted, recursive, cancelled, and panicking runs, calls through generated query APIs, and an unannotated query beneath an annotated caller. Hand-reviewed traversals identify the architectural operations, Rust declaration sites, parentage, and cache outcomes. A warm forbidden request must fail even when its body does not execute. | ||||||||||||||
correspondence | Implemented | Implemented | ||||||||||||
Every Sage correspondence unit has one or more Rust locations declared through
Verification exercises missing locations, dangling annotations, wrong crates, incompatible operation kinds, multiple sites, abstract markers, Cargo library and binary roots, and declarations produced by supported generators. Arbitrary macro tokens do not establish a generated declaration’s existence. | ||||||||||||||
observation_coverage | ImplementedTODO | ImplementedTODO | ||||||||||||
Incomplete observation cannot establish conformance. Unmapped requests, unsupported receiver checks, and uninstrumented effects remain explicit gaps. Strict acceptance requires complete checking of the declared scope, as well as absence of violations. Diagnostics identify the checking scenario, relevant model rule when one exists, and observed call path; an unknown mapping is not silently attributed to the caller. Verification injects each gap into an otherwise passing scenario and requires an incomplete or failing result, including cached requests and unsupported async boundaries. A call-only report does not claim that input reads, context construction, ordinary uninstrumented helpers, or task propagation were checked. | ||||||||||||||
validated_session | ImplementedTODO | ImplementedTODO | ||||||||||||
A checking session uses one immutable, validated contract model and its source correspondence index. Every event refers to that same snapshot. Enabled enforcement fails if its model is missing or invalid, or if the indexed Rust source cannot be paired with the running binary. Loading is cached for the session; source edits take effect only in a subsequent session. Verification exercises cached loads, parallel first use, explicit model roots, missing and invalid files, source/build mismatch rejection, and a subsequent session seeing model edits. Independently configured fixture sessions can use different models without modifying an active session. | ||||||||||||||
| meta.language (39) | 39 Implemented | 39 Implemented | ||||||||||||
| meta.language.calls (2) | 2 Implemented | 2 Implemented | ||||||||||||
declared | Implemented | Implemented | ||||||||||||
Every observed architectural call must be permitted by its caller’s resolved dependency envelope. An undeclared call is an error, including recursive entry into the same operation and requests satisfied from a query cache. | ||||||||||||||
forbidden | Implemented | Implemented | ||||||||||||
An observed operation must not violate a prohibition of any active ancestor, even when its immediate caller permits the call. A violation is an error and retains the prohibition and complete call path. | ||||||||||||||
| meta.language.classes (3) | 3 Implemented | 3 Implemented | ||||||||||||
abstract_complete | Implemented | Implemented | ||||||||||||
A concrete class must implement every inherited abstract method. | ||||||||||||||
override_signature | Implemented | Implemented | ||||||||||||
An overriding method must preserve the inherited method’s operation kind and resolved result type. | ||||||||||||||
single_inheritance | Implemented | Implemented | ||||||||||||
A class or context declaration has at most one | ||||||||||||||
| meta.language.contexts (1) | 1 Implemented | 1 Implemented | ||||||||||||
inheritance | Implemented | Implemented | ||||||||||||
Contexts are a distinct declaration kind and may inherit only from contexts. An ordinary or abstract class cannot inherit from a context. | ||||||||||||||
| meta.language.envelopes (7) | 7 Implemented | 7 Implemented | ||||||||||||
class_calls | Implemented | Implemented | ||||||||||||
| ||||||||||||||
creates | Implemented | Implemented | ||||||||||||
| ||||||||||||||
direct_calls | Implemented | Implemented | ||||||||||||
Each invocation clause grants a direct dependency. Transitive reachability is derived from those direct edges and does not grant the caller permission to invoke an indirect dependency directly. | ||||||||||||||
leaf | Implemented | Implemented | ||||||||||||
An empty envelope describes a leaf operation with no modeled dependencies. It is distinct from an abstract method, which has no declared envelope. | ||||||||||||||
permissions | Implemented | Implemented | ||||||||||||
Declared calls are permissions: none must occur, and calls may occur in an order different from the order of their envelope clauses. | ||||||||||||||
reads | Implemented | Implemented | ||||||||||||
| ||||||||||||||
receiver_calls | Implemented | Implemented | ||||||||||||
| ||||||||||||||
| meta.language.fields (2) | 2 Implemented | 2 Implemented | ||||||||||||
context_state | Implemented | Implemented | ||||||||||||
A | ||||||||||||||
kinds | Implemented | Implemented | ||||||||||||
Fields retain their declared | ||||||||||||||
| meta.language.methods (2) | 2 Implemented | 2 Implemented | ||||||||||||
kinds | Implemented | Implemented | ||||||||||||
Methods retain their declared operation kind: Queries describe memoized semantic products; functions describe ordinary computation. These annotations document boundaries; the model has no evaluator or cache. | ||||||||||||||
prose | Implemented | Implemented | ||||||||||||
Every method body begins with a triple-quoted description, followed by its
| ||||||||||||||
| meta.language.model (3) | 3 Implemented | 3 Implemented | ||||||||||||
forbidden_paths | Implemented | Implemented | ||||||||||||
| ||||||||||||||
inherited_prohibitions | Implemented | Implemented | ||||||||||||
An overriding implementation inherits the prohibitions of the base method. Prohibitions record design intent even when the permitted graph already excludes the target. Adding a permitted edge must still fail validation if it creates a forbidden path. | ||||||||||||||
virtual_dispatch | Implemented | Implemented | ||||||||||||
The checker resolves declared calls conservatively, including every known overriding implementation in the supplied model. | ||||||||||||||
| meta.language.types (19) | 19 Implemented | 19 Implemented | ||||||||||||
argument_arity | Implemented | Implemented | ||||||||||||
Each named type application must supply exactly the declared number of type arguments. This applies to opaque types, built-in types, parameters, and nested applications; a type parameter takes zero arguments. | ||||||||||||||
declaration_prose | Implemented | Implemented | ||||||||||||
A struct or enum can carry triple-quoted prose immediately inside its opening brace. The parsed declaration retains that text; omitting it is permitted. | ||||||||||||||
enum_variants | Implemented | Implemented | ||||||||||||
An | ||||||||||||||
field_prose | Implemented | Implemented | ||||||||||||
A named field can carry triple-quoted prose immediately before its name. The parsed field retains that text independently of the containing declaration or variant’s prose. At the start of a body, the first prose string describes the container; a description for its first field follows as a second string. | ||||||||||||||
generic_parameters | Implemented | Implemented | ||||||||||||
Structs, enums, and opaque types can declare a nonempty comma-separated list of type parameters in angle brackets. Parameters are available throughout their own declaration and do not become names in other declarations. | ||||||||||||||
member_commas | Implemented | Implemented | ||||||||||||
Adjacent named fields, enum variants, and tuple payload elements require a comma separator. A trailing comma before the closing delimiter is optional. For example:
| ||||||||||||||
name_resolution | Implemented | Implemented | ||||||||||||
An unqualified type name resolves first to a parameter of its declaration, then to a type, class, or context in the same module, then to the built-in prelude. An earlier match shadows a later one. | ||||||||||||||
opaque_representation | Implemented | Implemented | ||||||||||||
An opaque | ||||||||||||||
prelude | Implemented | Implemented | ||||||||||||
The built-in prelude contains | ||||||||||||||
qualified_names | Implemented | Implemented | ||||||||||||
A type outside the current module requires a | ||||||||||||||
recursive_values | Implemented | Implemented | ||||||||||||
Semantic value types can refer directly to themselves or to each other, without
| ||||||||||||||
struct_fields | Implemented | Implemented | ||||||||||||
A | ||||||||||||||
tuples | Implemented | Implemented | ||||||||||||
Parentheses always denote a tuple, including | ||||||||||||||
type_expressions | Implemented | Implemented | ||||||||||||
Type expressions are named types with optional generic arguments, or tuples. Generic arguments and tuple elements are themselves type expressions, allowing arbitrary nesting. The parsed expression retains that nesting. | ||||||||||||||
unique_fields | Implemented | Implemented | ||||||||||||
Named fields have distinct names within a struct or a single enum variant. Different declarations and different variants may reuse field names. | ||||||||||||||
unique_parameters | Implemented | Implemented | ||||||||||||
A value declaration cannot repeat a type parameter’s name. | ||||||||||||||
unique_variants | Implemented | Implemented | ||||||||||||
Variants have distinct names within an enum. Different enums may reuse a variant name. | ||||||||||||||
unknown_names | Implemented | Implemented | ||||||||||||
Every type name in a value field, variant payload, class or context field, or method result must resolve. An unknown name is an error even when nested in generic arguments or tuples. | ||||||||||||||
variant_prose | Implemented | Implemented | ||||||||||||
A variant can carry triple-quoted prose immediately inside its payload’s opening delimiter, or immediately after a unit variant’s name. The parsed variant retains that text independently of other variants. | ||||||||||||||
| meta.reviews (27) | 27 Implemented | 27 Implemented | ||||||||||||
claim_text | Implemented | Implemented | ||||||||||||
An anchor’s review text is the complete source content selected by the
anchor-content boundaries, with surrounding
whitespace removed. For | ||||||||||||||
complete_test_set | Implemented | Implemented | ||||||||||||
One review covers one anchor’s claim and its complete set of associated tests. The input records every eligible test associated with that anchor in a deterministic order. Several tests may cover different parts of a claim; each test need not establish the whole claim independently. | ||||||||||||||
decisions | Implemented | Implemented | ||||||||||||
An empty Ordinary, | ||||||||||||||
fragment_associations | Implemented | Implemented | ||||||||||||
The complete association set and its metadata remain checked separately from fragment contents. Adding, removing, or changing an association invalidates the review even when all saved fragments still resolve to unchanged text. | ||||||||||||||
fragment_format | Implemented | Implemented | ||||||||||||
Each fragment records its workspace-relative source path, selector, and exact selected contents. Contents are stored as source lines; joining them with newline characters recovers the selected text, including its whitespace and line endings. The data model is defined below in Rust notation, without prescribing a JSON encoding:
| ||||||||||||||
fragment_freshness | Implemented | Implemented | ||||||||||||
Recording and checking resolve every fragment’s selector against current source and compare the selected text with the saved text using exact string equality. A missing or ambiguous selection, invalid selector, or changed selected text makes the validation stale or invalid. No selector kind or input origin bypasses these checks. | ||||||||||||||
gate | Implemented | Implemented | ||||||||||||
The shared A validation for an anchor ID absent from the current specification also fails the gate, even when every current anchor has a passing validation. Diagnostics name that directory and direct the reviewer to remove obsolete records or reconcile renamed anchors and start fresh validation. Checking and recording do not silently delete stale anchor IDs. Invalid record formats, unsupported schema/policy versions, and incomplete records fail the gate. CI and workspace Cargo tests use this same gate; checking never creates approvals. | ||||||||||||||
input_format | Implemented | Implemented | ||||||||||||
The input contains these fields:
The following anchors define each part. Source text belongs in the uniform fragment collection; association metadata identifies the evidence and its declared status. The collection contains both initial context and later reads. | ||||||||||||||
input_fragments | Implemented | Implemented | ||||||||||||
Every piece of source context supplied to or consulted by a validation agent is recorded in one uniform collection of input fragments, whether prepared automatically, supplied by a coordinator, or declared by the reviewer. Helpers and surrounding context used during review are additional fragments; recording only the initial claim and tests does not excuse omitting other context used. Automatic preparation and recorded reads use the same fragment representation and freshness checks. Reviewers are responsible for declaring every source dependency used in their assessment. | ||||||||||||||
output_format | Implemented | Implemented | ||||||||||||
The output contains only the reviewer, report, and requested edits:
| ||||||||||||||
preparation | Implemented | Implemented | ||||||||||||
Starting a review validates the requested anchor against the current inventory,
then clears any existing validation for that anchor and sets up
Starting removes the previous output. After a successful start, the validation
directory must be in a state
that makes | ||||||||||||||
record_required | Implemented | Implemented | ||||||||||||
For every anchor requiring re-evaluation, Recording is necessary but not sufficient: the recorded report must be complete, request no edits, and still match current inputs. Recording a report that requests edits, or changing inputs after recording, leaves the gate failing. Every required anchor must meet these conditions independently. | ||||||||||||||
recorded_reads | Implemented | Implemented | ||||||||||||
The recorded-read command takes an anchor with an active review directory, a
workspace-relative source path, and a selector from
meta.reviews.fragment_format. A read without an explicit selector
selects the whole file. It appends the selected contents and selector directly
to that anchor’s Reviewers declare every additional source dependency through this command and are responsible for the completeness of those declarations. | ||||||||||||||
recording | Implemented | Implemented | ||||||||||||
Recording takes a completed report in the format defined by
meta.reviews.output_format and an anchor with an active unfinished review.
It checks the inputs already stored in that anchor’s directory against current
source using meta.reviews.fragment_freshness and
meta.reviews.fragment_associations, and verifies the anchor and version
metadata. Missing or stale inputs, an unknown anchor, an invalid report, or an
absent active review rejects recording. A changed input requires a new review
starting with On success, recording writes | ||||||||||||||
review_delegation | Implemented | Implemented | ||||||||||||
The repository’s The subagent uses | ||||||||||||||
review_diagnostics | Implemented | Implemented | ||||||||||||
CLI and Cargo-test failures identify every anchor requiring re-evaluation and
explain why: missing or unfinished validation, changed inputs or associations,
unsupported versions, malformed records, or requested edits. Changed-input
diagnostics identify the affected fragment or association. Failures direct the
main agent to invoke | ||||||||||||||
review_instructions | Implemented | Implemented | ||||||||||||
Review inputs preserve the exact verification prompt and any additional coordinator instructions supplied to the reviewer. These instructions are part of the recorded context even when they do not originate in a source file. | ||||||||||||||
review_scope | Implemented | Implemented | ||||||||||||
One review judges both implementation completeness and test adequacy against an anchor’s complete claim. Its saved input includes every implementation association’s crate, target, module, file, cfg conditions, excerpt, region flag, placeholder status, and explanation, in deterministic order. Source line numbers and byte offsets are not association metadata. Source context used to assess these associations is recorded under meta.reviews.input_fragments. A point marker’s five-line preview is navigation context, not a sufficient boundary for reviewing behavior that depends on other code. Reviewers follow relevant helpers and dependencies and record the source fragments they use. They add implementation associations for essential code in other files before approval. Reviews are source judgments, not proofs; test execution remains separate evidence. | ||||||||||||||
selector_claim | Implemented | Implemented | ||||||||||||
| ||||||||||||||
selector_line_range | Implemented | Implemented | ||||||||||||
| ||||||||||||||
selector_test | Implemented | Implemented | ||||||||||||
| ||||||||||||||
selector_whole_file | Implemented | Implemented | ||||||||||||
| ||||||||||||||
source_representation | Implemented | Implemented | ||||||||||||
Claim, implementation, and annotated test source snapshots are stored in | ||||||||||||||
staleness | Implemented | Implemented | ||||||||||||
A saved review applies only when its anchor, schema version, review-policy version, complete claim, and implementation and test inputs match the current inventory. Source context must satisfy meta.reviews.fragment_freshness and associations must satisfy meta.reviews.fragment_associations. Unchanged claims and tests remain reusable when unrelated edits move them, as specified by their selectors. Changed text within a whole-file fragment, including blank-line changes, invalidates that fragment. A reusable review must also have a complete output under meta.reviews.output_format and no requested edits under meta.reviews.decisions. | ||||||||||||||
summary_format | Implemented | Implemented | ||||||||||||
The summary contains these fields:
Freshness is determined by comparing the recorded inputs with current source, as defined by meta.reviews.fragment_freshness. | ||||||||||||||
test_source | Implemented | Implemented | ||||||||||||
Each associated test’s review input contains the complete annotated Rust
function source, including its attributes, signature, body, and contained
comments. It also records the Cargo crate and target, Rust path, file path,
inherited configuration conditions, and ordinary, | ||||||||||||||
validation_layout | Implemented | Implemented | ||||||||||||
Each anchor has one directory named by its complete dotted ID, for example:
| ||||||||||||||
| meta.validation (3) | 3 TODO | 3 TODO | ||||||||||||
claim_specific_evidence | TODO | TODO | ||||||||||||
Evidence is attached to one architectural claim. A statement that a behavior is established identifies evidence exercising that particular behavior, while a negative or partial artifact may pin a known limitation. A passing aggregate suite is not evidence for an unstated local guarantee. Verification scenarios: Documentation review checks every implemented capability against a focused test, snapshot, normalized trace, edit experiment, exact oracle result, inspector scenario, or source anchor whose asserted behavior matches the claim. | ||||||||||||||
independent_inspection | TODO | TODO | ||||||||||||
Human inspection and exact conformance remain independent. Readable Sage-only views explain semantic values and incremental work; the Oracle independently decides compatibility from Sage and rustc emissions. Neither facility consumes the other’s output to repair or reinterpret a result. Verification scenarios: Architecture and dependency tests keep inspector adapters out of oracle comparison and rustc-oracle values out of inspector rendering, while one pinned slice supplies both independently produced forms of evidence. | ||||||||||||||
review_packets | TODO | TODO | ||||||||||||
A review packet connects result, dependency, edit, and code evidence. For one semantic target, the packet identifies the Rust input, readable result, diagnostic/completeness outcome, cold and warm dependencies, relevant or unrelated edit behavior, focused or oracle verification, and anchored implementation entry points. Verification scenarios: Each designated review packet contains or links all seven elements, and its reproduction commands regenerate the checked-in artifacts without relying on unrecorded setup. | ||||||||||||||