Gap
relationships[] in schemas/v1/repository.schema.json is a closed enum:
portfolio-membership | git-submodule-consumer | package-consumer |
workflow-module-consumer | fork-of | device-checkout | worktree |
embedded-context-source
None of these expresses "repository A renders repository B" — a real, one-directional generator relationship where the rendered tree must never be hand-edited.
Concrete consumer
NDDev-it-com/setup-systems (private authoring monorepo) renders seven public trees:
NDDev-OpenNetwork/{claude,codex,grok,pi,opencode,cursor,antigravity}-setup-system
tools/render_public_trees.py::gds_repository_yaml emits their anchors, and a check clones all seven and requires byte-for-byte equality with the rendered output. The relationship is enforced in their tooling but is invisible to GDS. Today it can only be stated as prose in product.purpose.
Why the nearest neighbour is wrong
embedded-context-source requires materialization: ephemeral | persistent | forbidden. forbidden would carry the "never edit directly" half, but the type means context embedding, not rendering. Using it would make the anchor say something untrue.
Proposal
Add one additive enum member, declared on the generated repository pointing at its generator — same direction as fork-of:
relationships:
- type: "generated-from"
target: "repo_01M0QNDKCJ0K9XZHXVPCERB4XK"Additive, so it cannot invalidate existing anchors. Initially schema + validation only (target must resolve to a registered repository); no engine behaviour required. Later this is the natural place to hang a drift check that the rendered tree still matches its source.
Constraint worth recording
repository.schema.json sets additionalProperties: false, so any narrowing here invalidates all eight of those anchors at once, and their own render check would not notice — it proves the seven match their source, not that GDS still accepts them. Their gate is gds validate repository --json per checkout.
Verified today: all eight anchors pass against gds-v0.7.0 (public main 29a84e42). schema_version is still {"const": 1}.
https://claude.ai/code/session_01HMPUfMTrzqwrcgDCFvjnFG
Gap
relationships[]inschemas/v1/repository.schema.jsonis a closed enum:None of these expresses "repository A renders repository B" — a real, one-directional generator relationship where the rendered tree must never be hand-edited.
Concrete consumer
NDDev-it-com/setup-systems(private authoring monorepo) renders seven public trees:NDDev-OpenNetwork/{claude,codex,grok,pi,opencode,cursor,antigravity}-setup-systemtools/render_public_trees.py::gds_repository_yamlemits their anchors, and a check clones all seven and requires byte-for-byte equality with the rendered output. The relationship is enforced in their tooling but is invisible to GDS. Today it can only be stated as prose inproduct.purpose.Why the nearest neighbour is wrong
embedded-context-sourcerequiresmaterialization: ephemeral | persistent | forbidden.forbiddenwould carry the "never edit directly" half, but the type means context embedding, not rendering. Using it would make the anchor say something untrue.Proposal
Add one additive enum member, declared on the generated repository pointing at its generator — same direction as
fork-of:Additive, so it cannot invalidate existing anchors. Initially schema + validation only (target must resolve to a registered repository); no engine behaviour required. Later this is the natural place to hang a drift check that the rendered tree still matches its source.
Constraint worth recording
repository.schema.jsonsetsadditionalProperties: false, so any narrowing here invalidates all eight of those anchors at once, and their own render check would not notice — it proves the seven match their source, not that GDS still accepts them. Their gate isgds validate repository --jsonper checkout.Verified today: all eight anchors pass against
gds-v0.7.0(public main29a84e42).schema_versionis still{"const": 1}.https://claude.ai/code/session_01HMPUfMTrzqwrcgDCFvjnFG