Write down why companion declarations are copied between instances, not shared

Open Beginner friendly
#21 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
markdown
Domain
documentation

Research direction

Start with the Kind Catalog page or standing-up-a-foundry, the two locations named for the writeup. Document that companion declarations should be copied rather than imported, including the reasoning about independently observed layout and the limitation of transferred prose. Done means a new instance can find and understand this rule.

Written by the indexing model from the issue text.

Description

⚠️ Filed by Claude (AI assistant) on jmchilton's behalf — written by Claude, not authored by them personally.

Split out of #15 (question 6), where the decision was taken: keep duplicating. This issue is the "write it down" half.

The situation

Three kind declarations now name the same companions:

eval.md scenarios.md others
GWF mold rec · foundry-only rec · foundry-only 7 more
GWF pipeline rec · foundry-only rec · foundry-only examples/, README.md
SGF mold rec · foundry-only rec · foundry-only

pipeline's four are a strict subset of mold's nine, identical on both axes. By the ordinary rule — two callers is coincidence, three is a pattern — this is where a shared constant would go.

Why it does not go there

The third caller is in another repo. A constant shared inside galaxyproject/foundry covers two of the three; SGF would still declare its own.

A substrate-level set would destroy the evidence it looks like it captures. The Kind Catalog's strongest claim is that two independently-motivated foundries put the same two files beside a Mold, at the same requirement and the same disposition. Ship that set as a constant in @galaxy-foundry/kind-schema and the agreement becomes an artifact of the import — the page would be reporting that both instances read the same file. SGF's own mold/schema.ts says as much: "That the same two filenames arrived independently in both Foundries is the substrate claim the kind catalog can now make: a companion transferring is stronger evidence than a kind NAME transferring."

Honest qualification, and it belongs in the writeup. The files converged independently — SGF carries them beside 13/13 molds from practice. The declaration prose did not: the purpose strings are byte-identical across the repos, transcribed from GWF. The transfer evidence is real at the layout level and not at the prose level. galaxyproject/foundry-pattern#18's tests pin file, requirement and disposition, and deliberately never purpose.

The work

Record the rule where a new instance would actually look — the Kind Catalog page or standing-up-a-foundry, not a closed issue. It should say: copy the companion declarations, do not import them, and say why, so the repetition reads as deliberate rather than as an abstraction nobody got round to.

Worth stating the general form too, since it is the same reasoning #15 used for prompt: a substrate that prescribes layout stops being able to observe whether layout transfers.

Dominant language
Astro
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from galaxyproject/foundry-pattern

All issues in galaxyproject/foundry-pattern

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.