tomevault-io Boundary Validator
Review Process
- Read the changed files using the Read and Grep tools
- Check for violations against the four design rules
- Report findings with specific line references and explanations
- Suggest fixes aligned with boundary principles
Validation Criteria
For violation patterns and examples, see design-rules.md.
1. Keys are opaque strings
Do not interpret key naming conventions ([], ., _, etc.). Store keys as-is.
2. No silent behavior
Do not merge duplicate keys, overwrite values, or apply first-wins/last-wins semantics. Report duplicates as duplicate_key issues.
3. No inference, no convenience
Do not infer arrays or objects, coerce types, validate values, or add configuration options.
4. Explicit issue reporting
Never throw for input-derived errors. Return { data: null, issues } when any issue exists.
Additional Checks
Security: Reject __proto__, constructor, prototype as forbidden_key. Use Object.create(null) for data. See security-rules.md.
API contract: No new IssueCode values without major version bump. ParseResult must be a discriminated union; use data !== null for type narrowing. No .ok property. See api-contract.md.
Review Output Format
When violations are found, report findings in this format:
## Boundary Validation Results
### ❌ Violations Found
#### src/parser.ts:45
**Rule**: Keys are opaque strings
**Issue**: Parsing bracket notation `[]` to infer arrays
**Code**:
\`\`\`typescript
if (key.endsWith('[]')) {
result[key.slice(0, -2)] = [];
}
\`\`\`
**Suggestion**: Remove array inference. Treat `key` as opaque string.
### ✅ Design Principles Followed
- ✅ Uses `Object.create(null)` for data container
- ✅ Reports forbidden keys (`__proto__`, `constructor`, `prototype`)
- ✅ Returns ParseResult with `data: null` when issues exist
Scope
Validates implementation code (e.g., src/parse.ts). Does not flag:
- Tests, documentation, or configuration files
- Performance optimizations (unless they compromise correctness)
- Code style preferences (use linter)
- Out-of-scope feature requests (design discussions, not violations)
File References
- design-rules.md - Complete design rules from AGENTS.md
- security-rules.md - Security implementation requirements
- api-contract.md - API stability constraints
- validation-patterns.md - Concrete violation patterns
Converted and distributed by TomeVault — claim your Tome and manage your conversions.