What shipped on OpenVibe.Watch

Changelog

What shipped on OpenVibe.Watch, newest first. The plan is T18 ("Watch complete"); each entry names

the step it landed.

2026-10-13 — check-operation usage readings (plan T5 step 14, Watch slice)

<ul><li>A completed check queues one <code>platform.usage-sample@1</code> reading (metric <code>check-operation</code>, quantity 1, unit <code>check</code>,</li></ul>

operation and provider the carrier, subject the owner, project only when the watch names one, cost the run's

cost_usd) in the transaction that records its run, keyed watch:check:<run id>; a failed check is not billed.

<ul><li><code>server/billing.js</code> relays them to OpenVibe.Billing (<code>POST /api/v1/usage</code>, <code>billing.usage.record</code>) with the</li></ul>

openvibe-sdk/usage reporter; 400/422 rejects a reading, 429/5xx keeps it pending. /api/ready reports its counts.

<ul><li>Off by default (<code>WATCH_BILLING_INTERVAL_MS=0</code>). Migration <code>0008_billing_readings.sql</code>, <code>test/billing.test.js</code>.</li></ul>

2026-10-08 — account export and deletion (ADR-033)

<ul><li><code>POST /internal/events</code> (loopback, <code>WATCH_EVENTS_SECRET</code>) answers network.account.export_requested and</li></ul>

network.account.deleted through server/account-data.js over openvibe-sdk/account-data (SDK v0.37.0, was v0.36.0).

<ul><li><strong>Export:</strong> the person&#39;s watches.</li><li><strong>Deletion:</strong> their watches with every check run, observation and endpoint state under them, and their sessions.</li><li>The two subscriptions are created at boot. Migration <code>0003_account_data.sql</code>, nginx <code>location /internal/ { return 404; }</code>,</li></ul>

test/account-data.test.js.

2026-10-08 — the public site (T18 step 8)

<ul><li><strong>Sign in with OpenVibe</strong> at <code>/auth/login</code>: OAuth 2 authorization code with PKCE (S256) as the</li></ul>

Network client watch, a session in Watch's own database (only the hash of the cookie token is

stored), and the signed-in person's usr_… subject as the owner.

<ul><li><strong>A site for watches</strong>: the home page explains Watch and starts one of the four kinds; <code>/watches</code></li></ul>

lists yours; /watches/:id states a watch in plain words with its observation history and every

check run; pause, resume, delete and check-now are plain forms. Every page works without

JavaScript.

<ul><li><strong>One create form, four starting points</strong> (<code>/watches/new?template=page|price|feed|json</code>): a page</li></ul>

that changes, a price below a value, a new item in a feed, a JSON value — the server picks the

fields the kind needs.

<ul><li><strong>Honest by construction</strong>: the kinds that arrive later (event, webhook, Run, Node) and an AI</li></ul>

reading are not offered, because Watch will not pretend to check what it cannot. Notifications go

through OpenVibe.Network exactly as before.

<ul><li><strong>Crawl artifacts</strong> (robots.txt, sitemap.xml, llms.txt) and a public vhost that serves the site</li></ul>

while /api/v1/* stays loopback-only.

2026-10-08 — the check engine and the pull carriers (T18 steps 2–3)

<ul><li><strong>The watch registry</strong>: <code>watch.watch@1</code> in and out, validated with the released contracts; a</li></ul>

create needs a source, an extraction, a condition and an action; ownership is the authority and

another owner's watch is 404.

<ul><li><strong>The check engine</strong>: conditional GET (ETag/Last-Modified, a 304 costs no body), HEAD-first when</li></ul>

only "did it change?" matters, an unchanged body recorded as no_change, and a recorded state for

every terminal path with backoff and Retry-After.

<ul><li><strong>Carriers</strong>: <code>http</code>, <code>feed</code> (RSS 2.0 / RSS 1.0 / Atom 1.0) and <code>api</code> (JSON/XML, mapped), all</li></ul>

through the one SSRF-guarded fetcher with per-host spacing.

<ul><li><strong>Extraction and conditions</strong>: text, html, a small CSS subset, json/jsonpath and regex; <code>changed</code>,</li></ul>

the numeric and string predicates, for_sec debounce, tolerance and percent.

<ul><li><strong>Observations and check runs</strong>: immutable rows with value hashes, capped snapshots and retention.</li><li><strong>The API</strong> (bearer tokens, one capability per route), the <code>watch.*</code> events through the</li></ul>

transactional outbox, and per-actor limits.