In .github/bin/mif-project.js (around line 96), when a document's frontmatter carries x-superseded-by: <target>, the script projects this as { type: "supersedes", target: <target> }. This is inverted: x-superseded-by on document A naming document B means B supersedes A (A is the one being superseded), so the correct relationship type is superseded-by, not supersedes. As currently implemented, A's own MIF projection asserts that A supersedes B — the opposite of what the frontmatter field means.
The schema description at schemas/structured-madr.schema.json line 118 has the same inverted assumption baked into its docstring ("Projected to a MIF 'supersedes' relationship"), so the code and the schema documentation agree with each other and are both wrong — this isn't just a code slip, the intended behavior itself needs correcting.
Concrete real-world instance found while auditing docs: in modeled-information-format/gdlc's docs/decisions/adr-0004-project-config-surface.md, frontmatter carries x-superseded-by: adr-0006-eliminate-markdown-config-carriers.md (ADR-0004 was superseded by ADR-0006). Running mif-project.js against this file currently produces a relationship asserting ADR-0004 supersedes ADR-0006 — backwards from reality.
Suggested fix: change the relationship type pushed for x-superseded-by from "supersedes" to "superseded-by", and correct the schema field description to match.
Severity rationale: the incorrect direction is silent (no validation failure) and corrupts the machine-readable relationship graph for every ADR using x-superseded-by across every repo using this Action — the exact reason this Action's MIF projection exists per its own docs (the ADR genre skill markets relationships[] as how an agent answers "what replaces or realizes it?"). No crash, no data loss, and an author-supplied relationships[] override is an available workaround, so medium rather than high/critical priority.
In
.github/bin/mif-project.js(around line 96), when a document's frontmatter carriesx-superseded-by: <target>, the script projects this as{ type: "supersedes", target: <target> }. This is inverted:x-superseded-byon document A naming document B means B supersedes A (A is the one being superseded), so the correct relationship type issuperseded-by, notsupersedes. As currently implemented, A's own MIF projection asserts that A supersedes B — the opposite of what the frontmatter field means.The schema description at
schemas/structured-madr.schema.jsonline 118 has the same inverted assumption baked into its docstring ("Projected to a MIF 'supersedes' relationship"), so the code and the schema documentation agree with each other and are both wrong — this isn't just a code slip, the intended behavior itself needs correcting.Concrete real-world instance found while auditing docs: in
modeled-information-format/gdlc'sdocs/decisions/adr-0004-project-config-surface.md, frontmatter carriesx-superseded-by: adr-0006-eliminate-markdown-config-carriers.md(ADR-0004 was superseded by ADR-0006). Runningmif-project.jsagainst this file currently produces a relationship asserting ADR-0004 supersedes ADR-0006 — backwards from reality.Suggested fix: change the relationship type pushed for
x-superseded-byfrom"supersedes"to"superseded-by", and correct the schema field description to match.Severity rationale: the incorrect direction is silent (no validation failure) and corrupts the machine-readable relationship graph for every ADR using
x-superseded-byacross every repo using this Action — the exact reason this Action's MIF projection exists per its own docs (the ADR genre skill marketsrelationships[]as how an agent answers "what replaces or realizes it?"). No crash, no data loss, and an author-suppliedrelationships[]override is an available workaround, so medium rather than high/critical priority.