artifact-commons

A peer catalog to labor-commons, holding not professional boundaries but previously built solutions. The same reuse principle applies one layer up: a solution built by one business isn't scoped to that business. Any other operator can use it as-is or adapt it, without needing to know the catalog exists — that responsibility sits with the platform (commons-board / commons-crew), not the user.

Status: real and load-bearing. See open-labor-foundation/ARCHITECTURE.md for the full ecosystem picture. This repo holds the real board-addin content moved over from commons-artifacts — its addin-economy role moved here permanently, per that repo's own README. commons-board's addin-registry.ts reads this repo's catalog.json by default. commons-crew's search_artifacts action tool searches it as a governed, read-only tool — verified end to end against this exact repo. A pack can't be trusted as a real, working artifact on description alone: scripts/validate-catalog.mjs is the certification gate (see Certification, below), and runs automatically in CI on every push and PR — though neither this repo nor commons-keeper has branch protection configured yet, so a failing run doesn't currently block a merge, it only surfaces the failure. What's not built yet: nothing calls search_artifacts on its own initiative before a task reaches for build capability, commons-keeper's independent review coverage isn't live yet (see Certification, below), and in-product publishing from a running commons-board (no git required) is still a roadmap item.

What's here

board-addins/ — commons-board addins: a functional pack (governance rules, artifact schemas, seed data, UI routes) that installs into a running board and adds capability specific to an industry, org shape, or operating model. Each addin folder contains a manifest.json in the exact AddinManifest shape commons-board's addin-registry.ts already parses — this repo reuses that schema rather than inventing a new one. catalog.json at the repo root indexes every pack.

Two real packs migrated from commons-artifacts, both status: "available" with working schemas and seed data:

• gig-cooperative — service catalog, member interaction protocol, earnings distribution model, dispute resolution, onboarding tracks, professional review gate. For platform-based gig worker delivery cooperatives.
• startup-launch — venture profile, launch plan, tooling tracker, financial policy with spend controls. For founder-stage companies.

commons-artifacts also lists several status: "roadmap" packs — descriptions of hypothetical future functionality with no real manifest or schema behind them yet. Those stayed in commons-artifacts rather than moving here: an artifact catalog should hold artifacts, not placeholders for ones that don't exist.

Certification

GOVERNANCE.md's ratified model — an independent gate a pack must pass, plus an independent review loop, the same shape as labor-commons-curator + commons-keeper for labor-commons — applied to what an artifact actually is here:

• The gate: scripts/validate-catalog.mjs, run in CI on every push and PR (.github/workflows/certification-gate.yml). Checks each pack's manifest.json against the real shape commons-board's addin-registry.ts parses (schemas/addin-manifest.schema.json documents it), that every file a manifest claims (seeds, per-artifact-type schemas) actually exists, and that catalog.json hasn't drifted from the real manifests it's supposed to index. Caught a real bug during migration this way: gig-cooperative's manifest referenced seed files under the wrong names.
• The independent review: commons-keeper is meant to cover board-addins/ and scripts/ too, the same independent security-review loop that already runs against every other OLF repo. The config change is written (commons-keeper#1, not yet merged) — and even once merged, commons-keeper's target list is baked into its container image at build time, so it also needs an image rebuild and redeploy before the coverage is actually live, not just a merge. Don't treat this as covered until both have happened.

What's not here (yet)

• Standalone deliverables — commons-artifacts' other category (a generated deliverable, unzip and run, no board required). Checked directly: commons-artifacts has never actually had one. The category is described in that repo's README but zero were ever submitted — there's nothing real to migrate. Worth revisiting once (if) one exists; an empty category forked across two repos isn't worth the split.

License

By contributing, you confirm that you have the right to contribute this content and that you agree to license it under AGPL-3.0. See CONTRIBUTING.md.