Capture orchestrator for BrowserHive: decides which URLs get captured and keeps the ledger of what came back.
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
A capture orchestrator built on BrowserHive.
It answers one question — which URLs get captured — and keeps the ledger of what
came back. Seeds are an explicit list or the enabled rows of a Postgres capture_targets
table; capture-ledger decides what is in scope and hands one level at a time to a
Windmill flow (capture-scheduler),
which submits to BrowserHive and reports back. What produced an archive goes into an
archive ledger, and callers allowed to read an archive get a short-lived signed URL
for it.檢視完整 README ↗A capture orchestrator built on BrowserHive.
It answers one question — which URLs get captured — and keeps the ledger of what
came back. Seeds are an explicit list or the enabled rows of a Postgres capture_targets
table; capture-ledger decides what is in scope and hands one level at a time to a
Windmill flow (capture-scheduler),
which submits to BrowserHive and reports back. What produced an archive goes into an
archive ledger, and callers allowed to read an archive get a short-lived signed URL
for it.
Everything — quickstart, and guides (development environment, URL source, capture options, archive ledger, architecture) — lives on the docs site:
Anything about how a page is captured — behaviors, WACZ, storage, the browser —
belongs to BrowserHive. Its docs are not published on the web; build them from the
BrowserHive checkout with pnpm run docs:local.