Use this prompt to ask an AI system to validate an extract of a component.
You are validating a JSON export of a process module component definition.
Apply the following standards:
1. Folder structure
- Each folder contains all nodes for a single independent component.
- Folder name uses lower_snake_case and matches the component reference if applicable.
2. Component structure
- Type: ProcessSpecificationType.
- Name: Title Case (e.g., "Create Folder").
- Reference: UpperCamelCase with suffix "Component" (e.g., CreateFolderComponent).
- If used as a process type, reference may be in lower_snake_case.
- Includes at least one process via ProcessSpecificationElements.
- Options are structured as one object per component (e.g., "myComponent": { ... }).
- Option keys use lowerCamelCase.
- PermitPlaceholderOverridesIndicator should be true if placeholder overrides are used.
- system.NODE_DESCRIPTION is used for documentation. This is considered the lowest-level component.
3. Process definition
- Type: ProcessType.
- Each step has explicit name and script.
- Scripts use string values starting with "stepType" (e.g., `"stepTypeForm"`), **not** placeholders like `"${stepTypeForm}"`, and **must** match binding values declared in `system.BINDINGS`.
- No bindings other than step types are permitted in the process itself.
- All forms/scripts and other dynamic values must be referenced via **definition placeholders** in the form `"${componentReference.propertyReference}"`.
- next is always explicit.
- Status rules are embedded in the process step, unless they have url properties which indicate calls to folders from tasks.
- Placeholders (`${...}`) are used for options, `%{...}` for runtime.
4. Options and bindings
- All step types used in scripts are listed in `system.BINDINGS`.
- Non-step-type bindings must be private (if used).
- No script or form references directly in process config — they must go through options.
- Definition placeholders (`${componentReference.propertyReference}`) must be used for all configurable references in process definitions.
- The component’s `library.core.NodeOptions` must contain default values in the structure:
```json
{
"componentReference": {
"propertyReference": "..."
}
}
```
- Placeholder names and object keys use lowerCamelCase.
5. Documentation
- All variable options are documented in the component's system.NODE_DESCRIPTION.
- Runtime configuration does not need to be documented unless used.
- Each documented option should correspond to a property in the component's `NodeOptions`.
6. Option usage consistency
- Check for any placeholders used in the process of the form `${componentReference.property}`.
- For each placeholder:
- Confirm that the corresponding property is defined in `library.core.NodeOptions` under the correct component key.
- Confirm that the property is described in `system.NODE_DESCRIPTION`.
- Also check for any properties defined in `NodeOptions` or documented in `system.NODE_DESCRIPTION` that are not used in any process step.
---
Return a validation report in the following format:
### Validation report
**Summary**
Brief one-line summary of what the definition does.
**Folder and reference structure**
- [✓/✗] Folder structure and naming
- [✓/✗] Component and process references
**Component**
- [✓/✗] Name and reference format
- [✓/✗] Type = ProcessSpecificationType
- [✓/✗] Correct use of ProcessSpecificationElements
- [✓/✗] Component options structured under correct key
- [✓/✗] Option keys use lowerCamelCase
- [✓/✗] Overrides permitted if needed
- [✓/✗] system.NODE_DESCRIPTION present and appropriate
**Process**
- [✓/✗] Process type and name
- [✓/✗] Step scripts via stepTypeXXXX bindings only
- [✓/✗] No non-step-type bindings
- [✓/✗] Placeholders used correctly for options
- [✓/✗] next explicitly set for all steps
- [✓/✗] Status rules embedded where needed
**Bindings and placeholders**
- [✓/✗] All step types declared in system.BINDINGS
- [✓/✗] No forbidden bindings
- [✓/✗] Options not mixed with bindings
- [✓/✗] Placeholder names valid and structured
**Documentation**
- [✓/✗] Options documented in lowest-level component
- [✓/✗] Runtime config documented if used
**Option usage consistency**
- [✓/✗] All used options are defined in NodeOptions
- [✓/✗] All used options are documented in system.NODE_DESCRIPTION
- [✓/✗] All defined options are used in the process
- [✓/✗] All documented options are used in the process
Breakdown:
**Used but not defined**: ...
**Used but not documented**: ...
**Defined but not used**: ...
**Documented but not used**: ...
**Notes**
List any recommendations, unusual design decisions, or things worth checking manually.
**Actions**
List actions per node, titling and ordering nodes by system.NODE_NAME property.