ID:SPEC-148Status:draft
Relationships
Related 16
ID:SPEC-145Status:accepted
Composed runes
ID:SPEC-147Status:draft
Replacing the storytelling plugin with composed runes
ID:SPEC-146Status:shipped
Name resolution across rune boundaries
ID:ADR-036Status:proposed
Name the pattern; do not open a language
Date:2026-09-28
ID:ADR-039Status:proposed
Where a rune lives: three kinds of package, and one test
Date:2026-09-30
ID:SPEC-153Status:implemented
Delivering composed runes
ID:SPEC-130Status:shipped
Declarative schema.org mapping
ID:WORK-567Status:done
Group A — seven runes that assert a type and describe nothing
Priority:mediumComplexity:moderateMilestone:v0.35.0
ID:SPEC-149Status:draft
Business plugin composition audit
ID:SPEC-150Status:draft
Design plugin composition audit
ID:SPEC-151Status:draft
Marketing plugin composition audit
ID:SPEC-152Status:draft
Plan plugin composition audit
ID:SPEC-154Status:draft
Learning plugin composition audit
ID:SPEC-155Status:draft
Media plugin composition audit
ID:ADR-042Status:proposed
Metadata belongs to a rune's definition; themes override native runes only
Date:2026-10-10
ID:SPEC-156Status:draft
The ladder and row arrangement primitives
Branches 2
Summary
The second plugin audited against SPEC-145, after SPEC-147's storytelling. Places is 960 lines across three runes and three children, and the result differs from storytelling's in a way worth having in writing: it does not retire, it splits. Two runes compose; one never can, because it is not a domain rune at all.
It also establishes the per-property audit method, because per-rune verdicts proved unstable — twice in the course of this audit a rune was called composable or blocked on the strength of one property, when its other properties took different paths.
Why per-property, not per-rune
A schema row's source resolves through one of five paths, and only one of them is broken by composition (SPEC-146, Problem 2). Which path a property takes is a property of that property, not of its rune — so a rune with four properties can be three parts fine and one part broken, and a per-rune verdict is a coin toss on which property you happened to look at first.
| Path | Resolver | Across a composition boundary |
|---|---|---|
A — properties from an attribute | stamp → bag fallback (schema-table.ts:309-312) | works |
B — properties from a node | findAllByName (:235) | fails silently |
C — text | findByName, same walk | fails silently |
D — entities | buildEntity — node first, then bag (:384-395) | node source fails, attribute source works |
E — children | findChildren (:528) | works, and over-matches (SPEC-146 Problem 1) |
event is the clearest demonstration in the codebase, and its own source comment says so: "location … exists only as an attribute value, so the applier rebuilds a carrier from the field bag rather than stamping a node. headline / blurb come from pageSectionProperties and survive as refs, so those stamp in place. One table, three of the mechanism's resolution paths."
The audit
event — three paths in one table, one of them blocked
| Property | schema.org | Source | Path | Composed |
|---|---|---|---|---|
headline | name | ref from pageSectionProperties | B | lost |
blurb | description | ref from pageSectionProperties | B | lost |
date | startDate | attribute → properties meta | A | ✓ |
endDate | endDate | attribute → properties meta | A | ✓ |
url | url | attribute → properties meta | A | ✓ |
location | nested Place.name | attribute → entities | D (attribute) | ✓ |
Measured against today's applier, the same table over a declared and a composed tree:
// declared { "@type": "Event", "name": "Tech Conference 2025", "description": "Three days of talks.", "startDate": "2025-06-15", "endDate": "2025-06-17", "url": "https://example.com/register", "location": { "@type": "Place", "name": "San Francisco, CA" } } // composed — the header placed inside a {% card %} { "@type": "Event", "startDate": "2025-06-15", "endDate": "2025-06-17", "url": "https://example.com/register", "location": { "@type": "Place", "name": "San Francisco, CA" } }