Skip to content

Verification: an OMP update alone keeps it current; verify again only when OMP no longer publishes a routed model - #270

Merged
atyrode merged 3 commits into
mainfrom
fix/omp-update-keeps-verification
Oct 12, 2026
Merged

atyrode merged 3 commits into
mainfrom
fix/omp-update-keeps-verification

Conversation

@atyrode

@atyrode atyrode commented Oct 12, 2026 •

Copy link
Copy Markdown
Owner

Problem

A verified model list went stale (omp-changed) whenever the destination's OMP runtime artifact or OMP's bundled catalog revision moved, and the workbench then refused to save or launch until a paid re-verification ran. Every OMP update on a machine therefore asked every workspace on it to verify again, even when the catalog, the accounts and every routed model were unchanged. The session door never depended on that: it refuses only a routed model the present OMP does not publish (code_model_unpublished).

Observed on the preview: a workspace verified under OMP 18.8.6 read "OMP changed since models were verified. Verify again." Its catalog revision and accounts were unchanged and both routed models were still published; only the destination's runtime artifact had moved.

Change

  • domain/routing.ts: routedModels(catalog, routes) (leads and fallbacks, each once) and unpublishedModels(routed, published) (by provider and id together, each once, sorted) are the one rule. composeSession now uses them for code_model_unpublished; its behaviour is unchanged.
  • generator/verification.ts: verificationState takes unpublished, and the status unpublished replaces omp-changed. An OMP update alone (another artifact, or another catalog revision that still publishes every routed model) leaves the verification current, with changes.runtimeChanged/catalogChanged noting it. A dropped routed model outranks an account change. VerificationState.observed is removed; nothing read it.
  • generator/model-verification.ts: reads readModelCatalog for the routed providers only once the catalog revision moved past the recorded one, which publishes every model the verification laddered. The answer is judged only when it is for that same revision. The read fails open to the session door's re-check, and the docs say so.
  • generator/workbench-model.ts: the routed models are the local review's. It does not prune unserved fallbacks as the door does, because a verified list's provider that no account serves has changed the pool, which already asks to verify again.
  • Models sheet: the head reads verified 1h ago · OMP updated since after an update the routes survived. When a routed model was dropped, the head reads OMP dropped 1 model since verified and the verify step names the model (OMP dropped sol).
  • workflow.ts: words for code_model_unpublished. failureWords keeps a detail as written after words that end in a colon, so a model address is not capitalised.
  • scripts/verify-browser.ts: the OMP upgrade phase now asserts the new rule in both directions.
  • docs/configuration.md and docs/status.md state the rule and its evidence.

Account changes and unverified lists still verify first. No contract, schema, manifest, persisted format, door input or output, or OMP dependency changes.

Evidence

Head b70e3dba448f59a6eef5c8226df0f1a9b4fe40ca, on main 94c6d44ad3 (#269).

  • scripts/gate.sh with Bun 1.4.2 beside the pinned Manifold checkout, exit 0. It ran frozen installs, exact OMP preparation, tsc, 429 tests, the four Code bundles, the isolated packed consumer, the real browser verifier (PASS (412s)) and the native phase. The native results were atyrode.omp standalone-native-and-packaged-worker-boundaries and atyrode.code code-omp-native-model-tools.

  • Bundles at this head:

    • atyrode.code 7f34759c10a445590fa4831c98bea010108d59e20f3ef2a5c6800529d1f50225
    • atyrode.code.accounts 419fc1971898c1fb10662d0c6c2300118f73f2ce3f390d03227e1d8031bb6413
    • atyrode.code.generator 22a239624bc502e97094f1dfaea19698d0a61b568a7fcea884db97ab35c24f40
    • atyrode.code.usage 1a0aa1824f3e3f24e6d0c7d622d7418fd022a3f5637ba3a6403bf6cbfb2b70ec
  • Regression: an OMP update the routed models survive keeps the verification current, so the launch goes on without verifying (test/verification.test.ts) fails under main's rule, which returns omp-changed and makes verify the next step.

  • The workflow test runs a real fixture verification over an OMP that publishes its inventory's models. Moving the runtime artifact keeps it current; a republish that keeps every model gives current with catalogChanged; dropping Claude Opus gives unpublished: ["anthropic/claude-opus-5"].

  • domain/catalog-routing.test.ts: a fallback-only model (the audit advisor's a2) dropped from the published list is named once.

  • Real browser (gate): on a verified list's destination, a runtime-only upgrade keeps the launch the step, and Models reads … · OMP updated since. The catalog republished without the default lead makes verify models the ready step, and Models names it (OMP dropped <alias>). Nothing is saved.

  • Design lab (this branch's packed Code bundles, the pinned OMP bundles, a disposable server, Chromium), scenarios omp-updated and omp-dropped:

    • Main view: review, then the automatic review, against verify models.
    • Models heads: 10 models · verified 59m ago · OMP updated since, and a warning with OMP dropped retired (the lab's renamed id).
    • Nothing scrolls sideways with the panel at 390, 320 or 170 px; the head wraps.
  • Preview, read-only: the rule applied to the preview workspace's live reads (destination pins, catalog revision, account pool; owner dispatch, nothing written) gives current, with runtimeChanged: true, catalogChanged: false and unpublished: []; the next step is review.

  • Current-head CI at b70e3dba44: test (run 38228923272), plugins / verify (run 38228923897, including the real browser verifier and the composed native proof) and agent-policy (run 38228924185) passed.

Acceptance

  • An OMP update with an unchanged catalog and accounts keeps review and launch the next step.
  • A moved catalog that no longer publishes a routed model makes verifying again the next step, naming the model in Models.
  • Account changes and unverified lists still verify first.
  • Current-head CI.
  • Head-specific review verdict.

… when OMP no longer publishes a routed model
…ule; the browser proof, words and docs follow the new freshness rule
…d the evidence says the republish is synthetic
@atyrode

atyrode commented Oct 12, 2026

Copy link
Copy Markdown
Owner Author

Verdict: pass

Head b70e3dba448f59a6eef5c8226df0f1a9b4fe40ca.

  • An independent review of fdfaf9cd75 requested changes, all addressed in e947caba7d and b70e3dba44:
    • the browser phase still asserted the previous rule;
    • an evidence statement was imprecise;
    • the fail-open read of a moved catalog was undocumented;
    • a published list was not tied to the catalog revision;
    • the wording of the blocking head;
    • one routed-model rule for the panel and the session door;
    • a literal expectation in the workflow test;
    • two stale comments;
    • a capitalised identifier in the refusal words.
  • Delta reviews passed, the last one on this head.
  • scripts/gate.sh on this head, exit 0: 429 tests, browser verifier PASS (412s), native proofs atyrode.omp and atyrode.code. The verifier runs the OMP update phase unconditionally; on fdfaf9cd75, before the phase was rewritten, the gate failed in it.
  • Current-head CI passed: test 38228923272, plugins / verify 38228923897, agent-policy 38228924185.
  • Acceptance: an OMP update with an unchanged catalog and accounts keeps review and launch the next step; a moved catalog that no longer publishes a routed model makes verifying again the next step and names the model; account changes and unverified lists still verify first.

@atyrode
atyrode merged commit 49a3279 into main Oct 12, 2026
4 checks passed
@atyrode
atyrode deleted the fix/omp-update-keeps-verification branch October 12, 2026 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant