galaxyproject / galaxyproject/foundry-pattern
Per-directory content-type definitions (both instances) → generated type & tag catalogs on the pattern site
- Dominant language
- Astro
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
> ℹ️ Filed by Claude (AI assistant) on behalf of @jmchilton — not authored by them personally.
Two sequential phases: first make each content **kind** a self-contained, documented directory in both instances; then render **type + tag catalogs** on the pattern site to bootstrap new instances and make cross-foundry differences legible.
## Phase 1 — per-directory content-type definitions (both repos)
Today all kinds are defined in **one file per repo**: GWF `packages/note-schema/src/note-schema.ts` (a `z.discriminatedUnion("type", …)`), SGF `site/src/lib/frontmatter-schema.ts` (the `COLLECTIONS` map). Move to a directory where each kind is defined **and documented in isolation**:
```
types/mold/ schema.ts + kind.md (purpose + required metadata) + example.md
types/pattern/ schema.ts + kind.md + example.md
types/…/
```
A loader globs `types/*/` and assembles the discriminated union (GWF) / collections map (SGF) at build. Payoffs:
- **Isolation** — add a kind = add a directory; no editing a monolith; docs live where the schema does.
- **Reuse** — factor the substrate kinds (`mold`, `pattern`) and the shared base envelope (lifecycle/`tags`/license coherence) into a shared **`@foundry/note-kinds`** package both instances import; instance-specific kinds stay local directories. This lifts the **substrate/extension split** — already applied to the glossary — up to the content-type contract.
**Sequencing:** land galaxyproject/foundry#374 first (so kinds enumerate cleanly from the `type` discriminator, not the tag registry); jmchilton/statistical-genomics-foundry#100 settles the shared `tags` posture the base envelope encodes.
## Phase 2 — type & tag catalogs on the foundry-pattern site
Generate, from the same per-kind directories + tag registries:
- a **type catalog** — each content kind → required-metadata table + prose, rendered like the glossary renders from one file; substrate (shared) kinds vs instance-specific kinds shown side by side;
- a **tag catalog** — the namespaced/flat tag vocabularies per instance, shared vs divergent facets called out.
**Purpose:** (a) **bootstrap new instances** — a new foundry author sees the substrate kinds + required metadata to start from (pairs with `standing-up-a-foundry`, #11); (b) make the **similarities/differences between foundries** legible — the same evidence-of-abstraction the diff-from-parent framing wants. Lives near `anatomy-of-an-instance` / `standing-up-a-foundry`.
## Depends on / relates
- Phase 2 depends on Phase 1 (needs the per-kind directories, at least the substrate kinds).
- Tightly related to the scan/sync issue (#12): the catalog is essentially the **rendered, always-current form** of that scan. Build them to share the same source of truth.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading packages/note-schema/src/note-schema.ts and site/src/lib/frontmatter-schema.ts, then review galaxyproject/foundry#374, jmchilton/statistical-genomics-foundry#100, and related issue #12. Map the proposed per-kind directories, shared @foundry/note-kinds package, and pattern-site catalog location before attempting either phase. Done requires both instances to load documented per-kind definitions and the site to render type and tag catalogs from the shared source.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- markdown, typescript
- Domain
- build-system, documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100