RT
MVP ToDy95/OmniWork

Project intelligence

OmniWork

API-first job ingestion and distribution platform

An API-first foundation for validating, normalizing, deduplicating, and eventually distributing job listings through governed source and publishing contracts.

Latest signal

Aug 30, 2026

Synced Sep 1, 2026

6

Commits · 365 days

1

Pull requests · 365 days

0

Issues · 365 days

0

Code reviews · 365 days

Public summary

Public summary

What it is

OmniWork is an API-first foundation for ingesting, validating, publishing, distributing, and later monetizing job listings. It is designed as one modular product with explicit contracts between source connectors, domain rules, persistence, public APIs, and future distribution workers.

The problem and business value

Job data arrives in different shapes and with different publication rules. Without a stable boundary, source payloads, translations, deduplication, freshness, and distribution decisions become difficult to audit. OmniWork makes those decisions explicit so a future Jobs experience can preserve source facts, publish only approved content, and recover from connector or delivery failures.

The current repository is a foundation, not evidence of traffic, revenue, customer adoption, or live job distribution.

What it does today

  • Defines strict Zod contracts for source jobs, canonical English jobs, connectors, API errors, and pagination.
  • Implements a Greenhouse Job Board connector against the fixed official API origin with bounded timeout/retry behavior, HTML sanitization, hashing, and anonymized contract fixtures.
  • Provides a source-policy gate that distinguishes unreviewed, approved, partner, and blocked sources; public publication remains denied for the included unreviewed fixture.
  • Establishes modular domain, connector, observability, and database adapter packages, including an audit-preserving in-memory implementation.
  • Exposes health and readiness routes. Readiness intentionally reports that persistent storage is not available while only the in-memory adapter is present.

Integrations and data flow

The planned flow is source connector to normalization and deduplication, then an ow_* persistence boundary, governed enrichment, public API, and separately reviewed distribution. The code currently proves the connector and contract layers; it does not silently claim a Supabase migration, a hosted worker, or a production publishing channel.

OmniRoids is the planned AI and governance boundary for enrichment and copy variants. Any generated text remains subject to source fidelity, validation, approval, and the source's republishing policy.

AI or automation workflow

AI assistance is planned for classification, English canonicalization, and distribution variants. The implemented foundation is deterministic and contract-first. It does not execute autonomous publishing, and any future external side effect must remain approval-gated and auditable.

Lead, email, notification, or collaboration flow

No lead capture, email delivery, or external notification workflow is shipped in this repository. Future distribution and affiliate modules are planned as explicit outbox and reconciliation flows, separate from the source and canonical job records.

Security and privacy boundaries

Source access is not treated as permission to republish. Payloads, provider credentials, raw records, click data, and audit logs are intended to remain server-side. The repository uses strict validation, sanitization, source-policy checks, correlation IDs, bounded retries, and a database adapter boundary; the public API and hosted persistence still require implementation and review.

What is coming next

The next steps are the reviewed ow_* persistence layer, canonical job lifecycle and reconciliation, authenticated API behavior, approved source accounts, and browser evidence for the highest-risk journeys. Later work can add OmniRoids enrichment, official channel distribution, first-party redirects, and affiliate measurement only after policy, consent, provider, and operational gates are satisfied.

Current activity or evidence from the project

Recent repository work delivered the OW-001–OW-005 contract foundation, local quality gates, Greenhouse fixtures, health/readiness routes, and a database handoff that keeps persistence behind one adapter. The documented local tests, type checks, build, and audit checks support these implementation claims; they do not represent hosted persistence, live job ingestion, revenue, or production delivery.

Contribution graph

The work behind the work.

Commits, PRs, issues and reviews

All available activity

LessMore
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug

Recent activity

What is moving now.

Published roadmap

What is shipped and what comes next

This roadmap is a public-safe summary of the OmniWork foundation. It does not expose source payloads, credentials, private customer data, or unverified commercial outcomes.

Delivered

  • [done] Strict contracts for source jobs, canonical English jobs, APIs, pagination, and connectors.
  • [done] Modular TypeScript workspace with domain, connector, database, observability, and fixture boundaries.
  • [done] Greenhouse Job Board connector with fixed-origin requests, bounded timeout/retry behavior, sanitization, hashing, and anonymized fixtures.
  • [done] Source-policy gate that denies public publication for unreviewed sources.
  • [done] Audit-preserving in-memory adapter, health/readiness endpoints, and local quality gates.

Operationally pending

  • [in-progress] Review approved source accounts, terms, retention, provenance, and republishing rights.
  • [in-progress] Replace the development adapter with reviewed ow_* persistence and authenticated API evidence.
  • [in-progress] Complete hosted deployment, observability, recovery, and owner runbooks.

Coming soon

  • [planned] Canonical job lifecycle, versioning, freshness checks, deduplication, and reconciliation.
  • [planned] Public Jobs API and the razvantodica.com/jobs integration.
  • [planned] OmniRoids enrichment and approved, human-reviewed channel distribution.
  • [planned] First-party redirects, affiliate attribution, and revenue reconciliation after legal and provider review.

Product rule

Technical access to a source is never treated as permission to republish. Every source and external delivery path needs explicit policy, evidence, approval, and failure handling.

Back to live projects