Summary
EntityBinding.Stamp.Version in terms/src/main/java/dev/ikm/tinkar/terms/EntityBinding.java hardcodes statusFieldDefinitionIndex() through pathFieldDefinitionIndex() to 0–4. Each carries a WARNING: off by one because of missing stampField in the pattern comment and a TODO VALIDATE STARTER SET: change back to N when starter set if fixed. This workaround appears to be stale.
What the comments assume
That the real "STAMP version field pattern" (the pattern Stamp.Version.pattern() points at, UUID 73c798cf-bc77-49a2-84f7-4c0f4bc4c012) is missing a leading "stamp" field. Since every version structurally carries a stamp (EntityVersion.stampNid()), the intended design — confirmed by Component.Version.stampFieldDefinitionIndex() == 0 — is that any version-shaped meta-pattern's field 0 is the stamp itself, with type-specific fields following at index 1+.
What's actually declared (ike-starter-set)
Checked ike-starter-set's ike-terms/src/main/java/network/ike/foundation/ike/terms/foundation/Section71.java (original inception-declared content) and its later revision in PatternShapeRefinementSet.java: the "STAMP version field pattern" (same UUID) has declared a "STAMP field" at index 0 since inception, followed by Status(1)/Time(2)/Author(3)/Module(4)/Path(5) — six fields total, matching the intended design exactly. The "missing stampField" condition the comments describe doesn't hold today.
Suggested fix
statusFieldDefinitionIndex() → 1timeFieldDefinitionIndex() → 2authorFieldDefinitionIndex() → 3moduleFieldDefinitionIndex() → 4pathFieldDefinitionIndex() → 5- Remove the now-stale WARNING/TODO comments.
Before changing
Worth confirming there isn't a still-live reason for the workaround (e.g. an older/deployed store snapshot lacking the leading field) before removing it — this issue tracks the investigation/fix, it isn't asserting the change is risk-free. komet's observable-feature layer (ObservableComponent.getFeatures() / Feature<?> in komet/framework/.../observable/) is the consumer that would be affected.
Where this surfaced
Found while grounding an ike-starter-set documentation question (how ObservableComponent.getFeatures()'s ordering relates to the pattern-describing-the-pattern mechanism) against the real code — not from a runtime symptom.
Summary
EntityBinding.Stamp.Versioninterms/src/main/java/dev/ikm/tinkar/terms/EntityBinding.javahardcodesstatusFieldDefinitionIndex()throughpathFieldDefinitionIndex()to 0–4. Each carries aWARNING: off by one because of missing stampField in the patterncomment and aTODO VALIDATE STARTER SET: change back to N when starter set if fixed. This workaround appears to be stale.What the comments assume
That the real "STAMP version field pattern" (the pattern
Stamp.Version.pattern()points at, UUID73c798cf-bc77-49a2-84f7-4c0f4bc4c012) is missing a leading "stamp" field. Since every version structurally carries a stamp (EntityVersion.stampNid()), the intended design — confirmed byComponent.Version.stampFieldDefinitionIndex() == 0— is that any version-shaped meta-pattern's field 0 is the stamp itself, with type-specific fields following at index 1+.What's actually declared (ike-starter-set)
Checked
ike-starter-set'sike-terms/src/main/java/network/ike/foundation/ike/terms/foundation/Section71.java(original inception-declared content) and its later revision inPatternShapeRefinementSet.java: the "STAMP version field pattern" (same UUID) has declared a "STAMP field" at index 0 since inception, followed by Status(1)/Time(2)/Author(3)/Module(4)/Path(5) — six fields total, matching the intended design exactly. The "missing stampField" condition the comments describe doesn't hold today.Suggested fix
statusFieldDefinitionIndex()→ 1timeFieldDefinitionIndex()→ 2authorFieldDefinitionIndex()→ 3moduleFieldDefinitionIndex()→ 4pathFieldDefinitionIndex()→ 5Before changing
Worth confirming there isn't a still-live reason for the workaround (e.g. an older/deployed store snapshot lacking the leading field) before removing it — this issue tracks the investigation/fix, it isn't asserting the change is risk-free.
komet's observable-feature layer (ObservableComponent.getFeatures()/Feature<?>inkomet/framework/.../observable/) is the consumer that would be affected.Where this surfaced
Found while grounding an
ike-starter-setdocumentation question (howObservableComponent.getFeatures()'s ordering relates to the pattern-describing-the-pattern mechanism) against the real code — not from a runtime symptom.