• Descriptions of attributes or parameters defined by standards and specifications, such as SVG transform and CSS properties
• Descriptions of mathematical definitions, such as transformation matrices, color spaces, and interpolation formulas
• Descriptions of technical concepts, such as rendering pipelines and animation principles
• When knowledge validation finds an inconsistency between the documentation and a standard, further compare it with the implementation code to determine the actual behavior and identify the root-cause type

• Pure code-logic issues involving a "code and documentation inconsistency"
• Documentation structure, template, tag, or other formatting issues
• Consistency between SDK d.ts type definitions and documentation

• "Is this description in the documentation accurate?"
• "Is this parameter description correct?"
• "The documentation says X, but the standard says Y"
• "Check whether this description has the two meanings reversed"
• "Documentation correction" or "description validation"
• "Documentation-to-code comparison" or "Check whether the code implements it this way"
• "The standard says X, the documentation says Y, and what does the code actually do?"

1. Obtain the validation target: The user provides a documentation excerpt or an attribute name together with the specific description
2. Locate the documentation file: Search the documentation repository
3. Extract verifiable claims: Identify all verifiable knowledge-based statements in the documentation

• If an attribute or parameter comes from a W3C standard, such as SVG, CSS, or DOM, classify it as standard-specification type
• If the description involves mathematical formulas, matrix operations, or geometric transformations, classify it as mathematical-fact type
• If the description concerns common platform behavior that is not governed by a standard, classify it as competitive-benchmark type
• When uncertain, default to standard-specification type and attempt to locate the corresponding standard

• W3C SVG specification:

  https://www.w3.org/TR/SVG/

• CSS specifications:

  https://www.w3.org/Style/CSS/

• Web API specifications:

  https://developer.mozilla.org/

  (use MDN as a standards reference)
• Use WebSearch to search for

  {property name} W3C specification

• Use WebSearch to search for

  {concept} mathematical definition

• Compare multiple sources to confirm that the mathematical definition is consistent

• Android:

  https://developer.android.com/

• iOS:

  https://developer.apple.com/

• Web:

  https://developer.mozilla.org/

• Flutter:

  https://api.flutter.dev/

Documentation description → Authoritative validation source description → Consistent?

1. Parameter roles written in reverse: The descriptions of two parameters are swapped, such as the b/c values of an SVG matrix
2. Incorrect direction: The x/y direction or clockwise/counterclockwise direction is reversed
3. Incorrect type description: An integer is described as a floating-point value, a percentage as pixels, and so on
4. Incorrect default value: The default value differs from the standard
5. Missing or incorrect enumeration value: A standard enumeration value is omitted or assigned the wrong name
6. Scope described too broadly or too narrowly: The stated applicability differs from the standard

1. Locate the code repository
2. Trace through four layers:
   • Entry layer (frontend bridge):

     frameworks/bridge/declarative_frontend/jsview/

   • Data layer (property storage):

     frameworks/core/components_ng/property/

     ,

     frameworks/core/components/common/properties/

   • Processing layer (validation/clamping):

     frameworks/core/components_ng/render/

     ,

     frameworks/core/components/common/painter/

   • Rendering layer (drawing correction):

     frameworks/core/components_ng/render/adapter/

3. Compare actual values in the code: Locate default-value initialization, clamping logic, and fallback branches
4. Determine the root cause: Classify it according to the table above

• Specific file paths and line numbers, such as

  js_view_abstract.cpp:2198

• Key code snippets, including default-value assignments, conditional branches, and clamping logic
• Actual output values, including the combined result of the data and rendering layers

• Do not use the code implementation as the sole validation source for standard-specification claims. The code may contain bugs or deviations, while the standard is authoritative
• Do not classify an issue as a "documentation error" solely from the standard comparison. When a knowledge inconsistency is found, inspect the code to confirm the actual behavior, distinguish the root-cause type (A/B/C/D), and then decide whether to update the documentation or the code
• Do not determine parameter meanings from memory. In particular, mathematical concepts such as matrices and transformations must be checked against their definitions
• Do not ignore differences between standard versions. SVG 1.1 and SVG 2, for example, may differ, so the version referenced by the documentation must be confirmed

• Documentation: {file name}
• Section: {section name}

• Documentation location: {file:line}
• Documentation description: {original text}
• Standard description: {standard content}
• Actual code behavior: {code behavior}
• Verification basis: {standard link + code file:line}

• Type A: Update the documentation to align with the standard
• Type B: File a ticket to update the code
• Type C: Explain the documentation and code correction directions separately
• Type D: Add an "OpenHarmony extension relative to the standard" note to the documentation}

undefined

To quickly identify common error types, read references/common-errors.md.

1. Do not use the code implementation as the sole validation source for standard-specification claims: The code may contain bugs or deviations, while the standard is authoritative
2. Do not classify an issue as a "documentation error" solely from the standard comparison: When a knowledge inconsistency is found, inspect the code to confirm the actual behavior, distinguish the root-cause type (A/B/C/D), and then decide whether to update the documentation or the code
3. Do not determine parameter meanings from memory: In particular, mathematical concepts such as matrices and transformations must be checked against their definitions
4. Do not ignore differences between standard versions: SVG 1.1 and SVG 2 may differ, so the version referenced by the documentation must be confirmed
5. Do not treat competitor documentation as equivalent to a standard: Competitor documentation may also contain errors and should be used only as a cross-reference

1. No corresponding standard can be found: Expand the search scope or cross-validate against competitor documentation and mathematical definitions, and report the validation confidence level
2. The standard description is ambiguous: List the possible interpretations and validate each one
3. Standard versions conflict: Use the latest official version of the standard
4. The code path cannot be traced: Clearly inform the user that validation was not possible and list the paths that were searched; do not draw conclusions based on speculation
5. The code intentionally extends the standard (Type D): Add an "OpenHarmony extension relative to the standard" note to the documentation instead of requiring alignment with the standard

• references/common-errors.md — A library of common documentation error patterns; read it when you need to quickly identify common error types