Skip to content

docs(claude): distinguish domain vs. structural vocabulary in boundary rule#114

Merged
QMalcolm merged 1 commit into
mainfrom
qmalcolm--docs-library-boundary-rule
May 4, 2026
Merged

docs(claude): distinguish domain vs. structural vocabulary in boundary rule#114
QMalcolm merged 1 commit into
mainfrom
qmalcolm--docs-library-boundary-rule

Conversation

@QMalcolm

@QMalcolm QMalcolm commented May 4, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Splits the library boundary rule into two distinct categories: domain vocabulary (system-specific names that must never be hardcoded) and structural vocabulary (keys the library defines to interpret concept metadata, which it owns and must document/validate)
  • Adds a concrete heuristic: if no realistic second rule system would need a different value for a name, it is structural vocabulary
  • Makes the obligation to document and validate structural keys explicit

Why

The old rule was correct in intent but over-broad in application. It was being interpreted as "never hardcode any name in library source," which led to thin indirection layers (e.g. mode_field, cap_field) that added silent failure modes without adding real flexibility — and left ~20 metadata keys the library silently depends on undocumented and unvalidated.

The real distinction is: "fireball" is domain vocabulary (belongs in config); "required_count" is the library's own language for expressing a concept (belongs in library source, documented and validated).

…y rule

The old rule — "never hardcode concept IDs, type IDs, or field names" —
was correct for domain vocabulary (system-specific names like "fireball"
or "character_level") but was being applied too broadly to structural
vocabulary: the keys the library itself defines to interpret concept
metadata (e.g. "required_count", "preparation_mode", "always_prepared").

This caused two problems:
1. Structural keys were treated as if they should come from config,
   leading to thin indirection layers (mode_field, cap_field, etc.)
   that add failure modes without adding real flexibility.
2. The library accumulated ~20 metadata keys it silently depends on
   without documenting or validating them, because the rule implied
   owning those names was a violation.

The revised rule splits the boundary into two categories and adds a
concrete heuristic: if no realistic second rule system would need a
different value for this name, it is structural vocabulary and the
library owns it. This makes the obligation to document and validate
structural keys explicit, rather than treating them as a grey area.
@bito-code-review

Copy link
Copy Markdown

Bito Automatic Review Skipped - Files Excluded

Bito didn't auto-review because all changed files are in the exclusion list. You can change the excluded files settings here, or contact the agent instance creator at .

@QMalcolm QMalcolm merged commit 92516ed into main May 4, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant