Reusable component and package extraction candidates

This is a reuse analysis, not a shopping list. Reuse should be earned by repeated need, clear boundaries, and a stable enough API.

Maturity model

1. Local implementation.
2. Repeated pattern.
3. Documented pattern.
4. Extracted component.
5. Governed package.

Highest-value candidates

Candidate	Current evidence	Current maturity	Recommended next shape	Why first	Products helped
Ingestion run contracts	DataStitcher monitored ingestion, SiteIntel bulk ingest, BigQuery Atlas cataloguer, Bollocks Radar source worker all need run/step/retry/state patterns.	Repeated/documented pattern	@meridian-stack/works-ingest contracts only, no adapters yet	Strongest cross-project repeat with clear source/run/step/artefact vocabulary.	DataStitcher, SiteIntel, BigQuery Atlas, Bollocks Radar
Admin provider/secret status UI	Trackpal, Meridian Hub, SiteIntel, DataStitcher, BigQuery Atlas all need provider status, secret status, sync health, and safe manual actions.	Repeated pattern	Blueprint plus React components after two screens share props	Prevents every admin app building a slightly different secret-status surface.	Trackpal, Hub, SiteIntel, DataStitcher
Source/provider registry contract	Trackpal provider registry, DataStitcher source registry, SiteIntel bulk sources, BigQuery Atlas provider/candidate sources overlap.	Repeated pattern	TypeScript contract and documentation guide	Helps agents add integrations without inventing new status words and config fields.	Trackpal, SiteIntel, DataStitcher, BigQuery Atlas
BigQuery catalogue helpers	BigQuery Atlas, SiteIntel BigQuery worker, DataStitcher, and works-bigquery-catalogue all interact with BigQuery metadata.	Repeated implementation	Shared package or CLI adapter with hard safety docs	Metadata cataloguing can be expensive or unsafe if careless.	BigQuery Atlas, SiteIntel, DataStitcher
Generated docs and AI context patterns	Product repos and Product Compass use Docusaurus docs, generated project dossiers, runtime docs, and AI context files.	Extracted component for docs; local for Compass synthesis	Extend @meridian-stack/works-docs conventions and Compass scripts	The package exists; the missing piece is consistent project-owned capability metadata.	All product repos

Strong but not first

Candidate	Current evidence	Why not first
Domain/Public Suffix List registry	SiteIntel has detailed docs and BigQuery worker implementation; Trackpal and public audit tools could use it.	Needs a second real consumer before becoming a package.
Template dashboard renderer	Trackpal has a strong template model; DataStitcher and admin dashboards could benefit.	Keep local until another product renders from the same config shape.
Finding/evidence model	SiteIntel and Bollocks Radar both need cautious evidence-backed reports.	Copy and severity semantics are product-sensitive; start as a pattern.
Redacted agent telemetry export	Codex Sessions Analyser has a good privacy boundary.	Needs a Hub/Compass consumer before extraction.
D1 + R2 read-cache pattern	BigQuery Atlas uses D1 rows with R2 heavy payloads; Hub uses D1/R2 for reports.	Document as a pattern before package extraction.

Things that already look reusable

• Stable hashing, CSV/JSONL, timing, retry, and fetch helpers already exist in @meridian-stack/works-core.
• Docusaurus config, navigation, generated docs, schema rendering, Worker helpers, and shared docs styles already exist in @meridian-stack/works-docs.
• Cloudflare/GCP/Supabase setup and deployment helpers already exist in @meridian-stack/deployment.
• Meridian CLI already provides the human/CI front door over repo-owned config and commands.

Things that should remain local for now

• Google Fact Check source client and verdict dictionaries.
• Trackpal provider-specific OAuth connectors and metric interpretation.
• DataStitcher ABN raw/name-bearing rules and business data marts.
• SiteIntel competitor interpretation and owner-facing report copy.
• BigQuery Atlas candidate scoring heuristics until the crawler has live evidence across providers.
• Product-specific app layouts and public copy.

Repeated patterns worth documenting before extraction

Pattern	Products	Suggested doc shape
Public route validates and queues; private worker performs source work.	SiteIntel, Bollocks Radar, BigQuery Atlas	docs/patterns/public-queue-private-worker.md
Raw artefacts in object storage; summaries and pointers in database.	SiteIntel, DataStitcher, Bollocks Radar, BigQuery Atlas	docs/patterns/raw-artifact-boundary.md
Cloudflare app plus Google Cloud heavy worker.	SiteIntel, DataStitcher, BigQuery Atlas, Bollocks Radar	docs/patterns/cloudflare-gcp-split.md
Admin app behind Cloudflare Access.	Trackpal, SiteIntel, DataStitcher, BigQuery Atlas, Bollocks Radar, Hub	docs/patterns/access-protected-admin.md
Generated operation docs from deployment topology.	All hosted products	Existing works-docs docs plus Product Compass guide

Package candidates

@meridian-stack/works-ingest

Opportunity: Define source, run, step, artefact, validation, retry, source fingerprint, and safe progress contracts.

Keep it contract-first. Do not ship provider adapters in the first version.

@meridian-stack/works-admin

Opportunity: A React/view-model package for status badges, provider status tables, secret status, sync run summaries, retry action confirmations, and source lists.

Start as blueprints. Extract components only after Trackpal and one other admin app share the same props.

@meridian-stack/works-domain

Opportunity: Public Suffix List parsing, canonical host/domain normalisation, domain hierarchy edges, and source-sighting contracts.

Extract only when SiteIntel plus another product need the same package.

@meridian-stack/works-dashboard

Opportunity: Template-driven dashboard section resolver, metric card view models, alert lists, sync health panels, and source/freshness labels.

Keep Trackpal-local until DataStitcher or another app proves the same renderer is useful.

Schema candidates

• ingestion-source.schema.json
• ingestion-run.schema.json
• provider-registry.schema.json
• secret-status.schema.json
• capabilities.inventory.schema.json
• reuse-candidates.schema.json
• metric-definition.schema.json
• dashboard-template.schema.json

Docs and AI-context generation candidates

Product Compass should push source repos toward publishing:

• metadata/project-dossier.json
• metadata/capabilities.inventory.json
• metadata/reuse-candidates.json
• metadata/integrations.inventory.json
• docs/ai-context.md

Inference: The current absence of capability and reuse inventory files is the biggest reason Product Compass must author capability synthesis manually.

Extraction order

1. Document patterns in Product Compass.
2. Add capability/reuse inventory conventions to Product Compass docs.
3. Ask product repos to publish capability and reuse metadata.
4. Build works-ingest contracts only after DataStitcher and SiteIntel/BigQuery Atlas agree on common run vocabulary.
5. Create admin blueprints from Trackpal and Hub, then extract components if props converge.
6. Leave provider-specific adapters local until two products need the same implementation.

Sources consulted

• docs/architecture/meridian-works-shared-platform.md
• docs/packages/shared-package-boundaries.mdx
• packages/works/core/README.md
• packages/works/docs/README.md
• packages/tools/deployment/README.md
• projects/data-stitcher/docs/operations/reusable-monitored-ingestion-pattern.md
• projects/site-intel/docs/architecture/task-orchestration.mdx
• projects/bq-atlas/docs/architecture/shared-code-extraction-plan.md
• projects/trackpal/docs/product/21-dashboard-configuration-and-design.md
• projects/codex-sessions-analyser/README.md