galaxyproject / galaxyproject/foundry-pattern

Per-directory content-type definitions (both instances) → generated type & tag catalogs on the pattern site

Open
#13 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.