Repository navigation
chore(OMN-13034): regenerate stale lane-census snapshot (repo-wide CI blocker) - #2691
Merged
Merged
Conversation
Ran the documented procedure (scripts/check_lane_census_age.py's own error message): bash scripts/lane-census-check.sh --json --dry-run on .201 (read-only docker inventory probe, LANE_CENSUS_HOST pinned to the FQDN the systemd timer normally injects), committing the drift-event JSON blob as the new deploy/lane-census/census-snapshot.json. The prior snapshot (emitted_at 2026-07-29T22:26:53Z) was 9 days stale and failing 'Lane Census Staleness (OMN-13034)' on every PR in the repo. The fresh snapshot (2026-08-08T19:39:02Z) confirms the drift is real and has grown, not shrunk: prod is down 5 required containers (runtime-worker/agent-actions-consumer/skill-lifecycle-consumer/ intelligence-api/contract-resolver), stability-test is down the same 4 plus a failed forward-migration one-shot (exited 46h ago), and dev carries one manifest-undeclared container. This PR only refreshes the staleness signal to unblock the repo-wide CI gate; it does not remediate the drift itself (separate follow-up, filed per this PR's own generated ticket_body). verify: uv run python scripts/check_lane_census_age.py -> 'OK: census snapshot is 0h old'.
📝 WalkthroughWalkthroughThe census snapshot now records a critical failed stability-test migration finding. It updates the drift count, timestamp, alert key, ticket title, and ticket body. ChangesCensus alert update
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
|
OCC autobind did not mint a companion for this PR: no changed-file candidate could be proven RED against the merge base, and emitting a PR-existence probe instead would be non-falsifiable evidence (OMN-15247). Hand-authored evidence is required. |
jonahgabriel
pushed a commit
to OmniNode-ai/onex_change_control
that referenced
this pull request
Aug 8, 2026
#6213) * evidence: OCC companion pass 1 for OmniNode-ai/omnibase_infra#2691 * evidence(OMN-13034): replace inert self-referential receipts with live falsifiable evidence Contract Compliance Check BLOCKed OMN-13034: all 3 existing dod_evidence receipts (dod-infra-pr-2009, dod-occ-pr, occ-self-bind-pr-6213) are INERT -- the first two grep their own receipt tree written in this same PR (INSIDE_OWN_DIFF), the self-bind uses bare 'gh pr view' (NOT_EXECUTED, not the admissible 'gh api' compound token) -- 0/3 admissible, so no hosted-and-local effective check exists. The two pre-existing entries are merged-base (append-only, not edited here). Adds two net-new dod_evidence items instead, each independently falsifiable against a live surface outside this PR's own diff: - occ-census-freshness-live-2691: gh-api read of omnibase_infra#2691's committed census-snapshot.json at its head SHA, jq -e asserts emitted_at is within the 7-day gate (falsity FAILS per OMN-15747 jq -e semantics). - occ-census-local-verify-2691: fetches BOTH the snapshot and omnibase_infra's own check_lane_census_age.py gate script live via gh-api at the same pinned ref, then executes the real script with python3 against the downloaded content -- the script's own exit code is the proof. Both probes were run fresh and PASS; receipts embed verbatim probe_stdout. Evidence-Ticket: OMN-13034 --------- Co-authored-by: node-occ-companion-effect <occ-companion-effect@omninode.ai>
Contributor
✅ Hostile Reviewer — PASSEDBlocking findings (critical): 0 Gate semantics (pilot phase)
Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8468/OMN-8524) |
jonahgabriel
deleted the
jonah/omn-13034-regen-lane-census-snapshot-0808
branch
August 8, 2026 22:02
jonahgabriel
added a commit
that referenced
this pull request
Aug 9, 2026
…ixture Rebased onto origin/dev (4 commits: #2689 OMN-15740, #2690 OMN-15741 G1, #2691 lane-census, #2682 CI concurrency) to pick up dev's current tip before merge, closing the gap the PR-merge-ref CI checkout exposed: CI runs against branch+dev merged, not the raw branch head, so a test file added by #2689 (test_gateway_forwarder_service_handler_seam.py) was exercised by CI even though it did not exist on this branch's own tree. That file's _config() fixture predates #2690/G1's new required `canary` field on ModelGatewayForwarderConfig, so it failed 3 tests with a Pydantic "field required" error on any PR whose merge-ref included both commits -- a genuinely pre-existing bug on dev's current tip (confirmed via git stash against origin/dev by a sibling lane earlier today), not something introduced by this PR. Cherry-picked the isolated one-file fixture fix already authored for it (identical hunk from open PR #2697/OMN-15781, which bundles it with unrelated gateway auto_offset_reset work this ticket does not touch) rather than waiting on that PR to land first. Schema fingerprint re-verified unchanged (still 83 migration files, 8d57e961...) after rebase -- no new migrations landed. Local proof: tests/unit/nodes/node_bus_forwarder_effect/test_gateway_forwarder_service_handler_seam.py (3/3 passed), tests/integration/migrations/test_098_omninode_internal_schema_omn15359.py + tests/unit/topology/test_application_database_table_grants.py (57/57 passed). OMN-15359
jonahgabriel
added a commit
that referenced
this pull request
Aug 9, 2026
…physical bridge (#2674) * feat(OMN-15359): physically create omninode_internal schema + extend physical bridge P2-P4 build slice: absorbs the OMN-15426 48-table gap (rolling ledger 2026-08-03T19:2xZ) where handler_wiring issued schema-qualified SQL against contract-declared omninode_internal for the omninode_runtime table domain while the schema physically never existed anywhere in the migration corpus (every table lands unqualified in public). - docker/migrations/forward/098_create_omninode_internal_schema.sql: additive CREATE SCHEMA IF NOT EXISTS omninode_internal inside omnidash_analytics. No table created/moved/altered. Proven live against a real ephemeral Postgres cluster (5 integration tests: created, additive/zero-table, idempotent re-apply, rollback drops the empty schema, rollback fails closed via RESTRICT once a table has landed). - physical_schema_mapping.py: INTERNAL_TABLES_PHYSICALLY_IN_PUBLIC_UNTIL_OMN15359 (41 tables), mirroring the already-shipped TENANT bridge. Grant derivation and handler_wiring now resolve these tables against their real physical location (public) instead of a schema that holds nothing yet. - omninode_runtime gains USAGE ON SCHEMA public in all 3 topology source instances (local/onex-dev/onex-prod) -- a separate real gap the bridge alone doesn't close, mirroring tenant_projection_writer's existing grant. TABLE grants regenerated via generate_application_database_table_grants.py --write (live omnimarket sibling, 57 declarations, --check --prove clean across all 7 profiles) and docker/catalog/database-topology/*.yaml re-rendered. - Updated 5 pre-existing topology tests whose assertions depended on omninode_internal tables resolving against the (formerly nonexistent) omninode_internal grant schema; all now correctly account for the bridge. Deferred (named, not silent): per-family physical table copy (owned by the OMN-15420 cutover-journal machinery via P5 tickets OMN-15426/OMN-15360), owner_omninode_internal/omninode_runtime role creation, and the tenant-side physical move. Does not touch delegation_workflow_state (OMN-15337 lane, ruling R-q) or the OMN-15423 event_bus_events/schema_migrations dispositions -- neither table is in the omninode_runtime grant set this PR bridges. Evidence-Source: OMN-15359 * fix(OMN-15359): repair 2 seam bugs blocking infra#2674 merge Two independent bugs on jonah/omn-15359-p2p4-internal-schema-physical-bridge, both verified live before and after fix: 1. Schema fingerprint artifact was stale (migration_file_count: 82, generated 2026-08-03) relative to the branch's own 83 migration files (098_create_omninode_internal_schema.sql plus 2 vendored node migrations). `check_schema_fingerprint.py verify` reproduced the exact CI failure locally (expected 8d57e961... vs committed 40607d243...); `stamp` regenerates it to match. 2. docker/domain-adapter-proof/prove.py's INTERNAL_TABLE constant still said "generation_events", but this same PR's earlier commit renamed the fixture topology's omninode_internal-domain proof grant target to "future_internal_projection" (tests/fixtures/application_relation_ownership/ topology.yaml) -- generation_events is now bridged to public via INTERNAL_TABLES_PHYSICALLY_IN_PUBLIC_UNTIL_OMN15359, so it no longer belongs in the omninode_internal-native proof path. prove.py's raw DDL/GRANT block still worked (it doesn't read topology), but the topology-driven privilege check in handler_wiring.py's _require_projection_binding_privileges correctly consulted the fixture and found no grant for generation_events, raising exactly the live CI failure: "Projection binding 'omninode_runtime_service' ... lacks declared read privileges ... SELECT on table omninode_internal.generation_events". Renamed the constant (and the one hardcoded SQL string in the cross-domain isolation check) to match the fixture. Also added prove.py to the existing S608 per-file-ignores precedent (controlled module constant, not external input, matching the two existing integration-test entries). Reran docker/domain-adapter-proof/compose.yml locally end-to-end against a real Postgres 16 container after each edit: PASS (OMN-15421 rebuilt- container proof exit 0). Does not touch the two remaining red checks (CI Summary -- cascades from these plus a stale companion-OCC read, should clear on rerun once this lands; OCC Companion Merged Gate -- companion OCC#6185 closed unmerged against a now-stale head SHA, needs a fresh mint against this new head via the autobind/companion-effect pipeline on push). OMN-15359 * fix(OMN-15359): rebase onto dev + repair pre-existing broken canary fixture Rebased onto origin/dev (4 commits: #2689 OMN-15740, #2690 OMN-15741 G1, #2691 lane-census, #2682 CI concurrency) to pick up dev's current tip before merge, closing the gap the PR-merge-ref CI checkout exposed: CI runs against branch+dev merged, not the raw branch head, so a test file added by #2689 (test_gateway_forwarder_service_handler_seam.py) was exercised by CI even though it did not exist on this branch's own tree. That file's _config() fixture predates #2690/G1's new required `canary` field on ModelGatewayForwarderConfig, so it failed 3 tests with a Pydantic "field required" error on any PR whose merge-ref included both commits -- a genuinely pre-existing bug on dev's current tip (confirmed via git stash against origin/dev by a sibling lane earlier today), not something introduced by this PR. Cherry-picked the isolated one-file fixture fix already authored for it (identical hunk from open PR #2697/OMN-15781, which bundles it with unrelated gateway auto_offset_reset work this ticket does not touch) rather than waiting on that PR to land first. Schema fingerprint re-verified unchanged (still 83 migration files, 8d57e961...) after rebase -- no new migrations landed. Local proof: tests/unit/nodes/node_bus_forwarder_effect/test_gateway_forwarder_service_handler_seam.py (3/3 passed), tests/integration/migrations/test_098_omninode_internal_schema_omn15359.py + tests/unit/topology/test_application_database_table_grants.py (57/57 passed). OMN-15359 * fix(OMN-15359): regenerate stale runner-image identity lock Root-caused the "runner image shared_env_digest is stale" failure that was blocking CI Tests Gate (via runner-image-build-smoke and repeated Tests-split identity assertions) -- NOT a runner-fleet flake as it first appeared alongside genuine network-transport flakes today. This PR's own earlier commit added a pyproject.toml entry ([tool.ruff.lint.per-file- ignores] for docker/domain-adapter-proof/prove.py), and shared_env_digest is computed (scripts/ci/runner_image_identity.py::compute_shared_env_digest -> ci_env_digest.compute_digest) partly from pyproject.toml bytes -- so editing that file legitimately re-binds the runner image identity and the lock file needed regenerating in the same PR, per the module's own documented contract ("the lock file records the bound identity; CI verifies the recorded digest against the recomputed one"). Reproduced locally: `runner_image_identity.py --mode verify` failed with the exact recorded/recomputed pair from CI (e0abb945.../b5c24d81...); `--mode generate` + re-verify fixed it. tests/ci/test_runner_image_identity.py 12/12 passed after. OMN-15359 * chore(OMN-15359): retrigger CI (stuck Topic Drift Check job on prior attempt)
jonahgabriel
added a commit
that referenced
this pull request
Aug 22, 2026
…esh) The committed census snapshot went stale on 2026-08-15T19:39Z (emitted_at 2026-08-08T19:39:02Z, max age 7 days) and had not been refreshed since, failing the Lane Census Staleness gate on dev and on every open PR in the repo (e.g. #2842 needed it argued around). This is the third occurrence of the same treadmill; prior refreshes were #2691 (9-day-stale -> fresh) and an unlanded local commit from 2026-08-16 (folded into this one). Regenerated read-only on 192.168.86.201 via `bash scripts/lane-census-check.sh --json --dry-run` against the live Engine API inventory for stability-test/prod/judge/dev — no compose mutation, no lane touched. Drift is roughly unchanged in shape (drift_count 11 -> 12): the same 5 prod container_absent findings and the same dev unexpected_container warning persist, and stability-test's single oneshot_failed entry from 2026-08-08 has resolved (that migration container is no longer stuck) but 6 stability-test service containers (runtime-effects, runtime-worker, agent-actions-consumer, skill-lifecycle-consumer, intelligence-api, contract-resolver) are now absent instead of just 4 previously — a pre-existing degraded-lane condition this ticket only documents, not remediates (out of scope for a doc-freshness refresh; tracked separately by the runtime lane work already in flight this session). Verified locally before commit: check_lane_census_age.py reports 0h old; check_lane_env_drift.py (E-5) reports no drift; generate_claude_lane_block.py smoke-runs clean; 59/59 lane_census unit tests pass.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 23, 2026
…esh) (#2846) The committed census snapshot went stale on 2026-08-15T19:39Z (emitted_at 2026-08-08T19:39:02Z, max age 7 days) and had not been refreshed since, failing the Lane Census Staleness gate on dev and on every open PR in the repo (e.g. #2842 needed it argued around). This is the third occurrence of the same treadmill; prior refreshes were #2691 (9-day-stale -> fresh) and an unlanded local commit from 2026-08-16 (folded into this one). Regenerated read-only on 192.168.86.201 via `bash scripts/lane-census-check.sh --json --dry-run` against the live Engine API inventory for stability-test/prod/judge/dev — no compose mutation, no lane touched. Drift is roughly unchanged in shape (drift_count 11 -> 12): the same 5 prod container_absent findings and the same dev unexpected_container warning persist, and stability-test's single oneshot_failed entry from 2026-08-08 has resolved (that migration container is no longer stuck) but 6 stability-test service containers (runtime-effects, runtime-worker, agent-actions-consumer, skill-lifecycle-consumer, intelligence-api, contract-resolver) are now absent instead of just 4 previously — a pre-existing degraded-lane condition this ticket only documents, not remediates (out of scope for a doc-freshness refresh; tracked separately by the runtime lane work already in flight this session). Verified locally before commit: check_lane_census_age.py reports 0h old; check_lane_env_drift.py (E-5) reports no drift; generate_claude_lane_block.py smoke-runs clean; 59/59 lane_census unit tests pass.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 29, 2026
…sh, post-heal) (#2998) The committed census snapshot (deploy/lane-census/census-snapshot.json) was emitted 2026-08-22T21:16:59Z with drift_count=12, sitting exactly on the Lane Census Staleness gate's 7-day MAX_AGE_DAYS boundary. The stability-test lane heal landed under this ticket (OMN-16803) since that capture, so the snapshot was also stale relative to live reality: it still showed 6 stability-test service containers absent, which the heal resolved. Regenerated read-only from 192.168.86.201's live Docker Engine API inventory (GET /containers/json, GET /networks — no compose mutation, no lane touched), following the documented process (scripts/check_lane_census_age.py's own error message / prior refresh PRs #2846, #2691): capture the inventory via lane_census_inventory.py, then run the pure planner (lane_census_plan.py) and event builder (lane_census_event.py) against the current lane-manifest.yaml. Ran the planner/event builder locally against the repo's dev-tip manifest (rather than on .201's own checkout, which is 23 commits behind) so the desired-state definition matches this PR exactly. New snapshot: emitted_at=2026-08-29T06:50:04.768415+00:00, drift_count=2 (down from 12) — one prod container_absent (omninode-prod-runtime-worker) and one dev unexpected_container warning (omnibase-infra-forward-migration), both pre-existing and unrelated to the stability-test heal this ticket covers. All 6 stability-test container_absent findings are gone; stability-test lanes_checked now reads census-clean, consistent with the CLAUDE.md lane block already regenerated from live under this same ticket (commit 0eef58426). Verified locally before commit: - check_lane_census_age.py --max-age-days 7 -> OK, 0h old - check_lane_env_drift.py (E-5) -> OK, no drift - generate_claude_lane_block.py smoke-run -> clean, matches CLAUDE.md's already-regenerated stability-test row Ticket: OMN-16803 (the stability heal this snapshot documents)
jonahgabriel
added a commit
that referenced
this pull request
Sep 10, 2026
The committed census snapshot (deploy/lane-census/census-snapshot.json) was emitted 2026-09-02T12:28:09Z and crossed the Lane Census Staleness gate's 7-day MAX_AGE_DAYS boundary at ~2026-09-09T12:28Z, so `Lane Census Staleness + E-5 Env Drift (OMN-13034)` has been red on every open omnibase_infra PR since. This is the fourth occurrence of the same treadmill; prior refreshes were #2691, #2846 and #2998. Regenerated READ-ONLY against 192.168.86.201's live Docker Engine API inventory (GET /containers/json, GET /networks — 166 containers, 23 networks, inventory_source=engine_api, no stderr, no compose mutation, no lane touched), following the process the prior refresh PRs used: capture the inventory with lane_census_inventory.py, then run the pure planner (lane_census_plan.py) and the event builder (lane_census_event.py) against this branch's lane-manifest.yaml. The inventory script was shipped to a scratch path on .201 and checksum- matched to this branch's copy (md5 5c85a052ce1bbee97fff2893316284f4) rather than run from a checkout there, because .201 carries no canonical omnibase_infra clone and the desired-state definition must match this PR exactly. New snapshot: emitted_at=2026-09-10T10:06:57.003308+00:00, drift_count=6 (up from 2). Nothing here is hand-edited; the four added findings are what live state actually is. Two of the four are the direct, expected consequence of #3385 (OMN-18114), which merged as the current dev tip and added `omnimarket-stability-test-tenant-projection-writer` and `omnimarket-tenant-projection-writer` to the manifest's desired state. Neither lane has been rebuilt since that merge, so both read container_absent. The census is correct: desired moved, actual has not caught up yet. This snapshot documents that gap; it does not remediate it, and remediation is out of scope for a doc-freshness refresh. The other two are dev-lane unexpected_container warnings for `onex-api` and `omninode-infra-routing-decisions-consumer` — both running and healthy on the dev lane, both carrying com.omninode.lane='dev', neither declared in the manifest. Also documented, not remediated. The two findings already in the prior snapshot are unchanged: the prod `omninode-prod-runtime-worker` container_absent and the dev `omnibase-infra-forward-migration` unexpected_container warning. Verified locally before commit, all three of the gate's own steps: - check_lane_census_age.py --max-age-days 7 -> OK, 0h old - check_lane_env_drift.py (E-5) -> OK, no drift across all five lanes - generate_claude_lane_block.py -> renders clean - 73/73 lane_census unit tests pass Ticket: OMN-13034
This was referenced Sep 17, 2026
jonahgabriel
added a commit
that referenced
this pull request
Sep 17, 2026
AC2 of OMN-18606. omnibase_infra#3705 made the census emittable; nothing carried it back. Every entry in the committed snapshot's git history is a person opening a PR -- #2395, #2691, #2846, #2998, #3394, #3489 -- and a seventh (#3703, an unrelated lane) landed one by hand while this ticket was being written, forty minutes after the lane started. `lane-census-refresh.yml` runs every 6 hours on the `host-201` verify runner, collects the census, and opens a bump PR through the writer-App path with auto-merge armed. WHY IT COLLECTS RATHER THAN READING THE HOST'S FILE. The hourly drop-in writes a snapshot to ~/.local/state/onex/ on the lab host. This job cannot read it: `host-201` is carried by the omninode-verify-runner-1 CONTAINER, whose mounts are its creds volume, /var/run/docker.sock, the operator env file and three entrypoint scripts -- that state directory is not among them. Mounting it would be a runner-fleet recreate to gain nothing, because the socket it already mounts reaches the same daemon the host-side pass reads. Same daemon, same answer. If the socket is unreachable the collector exits 4 (fail-loud, OMN-15466) and no PR is opened. WHY NOT A PR EVERY RUN. `lane_census_refresh_decision.py` is the pure rule and it says no most of the time. Four unconditional PRs a day is how an automation earns itself an exemption. It refreshes when the committed census is unreadable, when `alert_key` shows the lane topology moved, or at 3 days -- well inside the gate's 7-day limit so the PR has days to land rather than racing the deadline. Two guards come first and both protect the committed state: a malformed candidate is an ERROR, never a refresh, and a candidate not newer than the committed one is always a no-op, so a skewed clock cannot manufacture the staleness this leg exists to prevent. 24 tests. The anti-churn one walks the clock across two days of scheduled runs against an unchanged fleet and fails if any of them would have opened a PR. Two incident replay cases, both real captured bytes rather than reconstructions, because the coverage gate's default-deny is right to demand them of new enforcement: - the actual stale census, read out of the git object store at 2e4eec0, driven through the real decision at 2026-09-17T10:07Z -- the instant the gate went red -- and required to say REFRESH, with a companion at day one required to say nothing. - the drop-in as it was ACTUALLY INSTALLED on .201, scp'd off the host while it was still the pre-fix copy. Its single ExecStart names the collector with no output destination and no redirect, and systemd runs execve rather than a shell so a redirect could never have worked there. That is the false_green: the unit reported SUCCESS every hour precisely because the census pass wrote nothing and so had nothing to fail. Claude-Session: https://claude.ai/code/session_01Mg3nhbHwH7a3UoKLhRMFKk
jonahgabriel
added a commit
that referenced
this pull request
Sep 17, 2026
…#3710) * feat(OMN-18606): the lab census reaches this repo without a hand-heal AC2 of OMN-18606. omnibase_infra#3705 made the census emittable; nothing carried it back. Every entry in the committed snapshot's git history is a person opening a PR -- #2395, #2691, #2846, #2998, #3394, #3489 -- and a seventh (#3703, an unrelated lane) landed one by hand while this ticket was being written, forty minutes after the lane started. `lane-census-refresh.yml` runs every 6 hours on the `host-201` verify runner, collects the census, and opens a bump PR through the writer-App path with auto-merge armed. WHY IT COLLECTS RATHER THAN READING THE HOST'S FILE. The hourly drop-in writes a snapshot to ~/.local/state/onex/ on the lab host. This job cannot read it: `host-201` is carried by the omninode-verify-runner-1 CONTAINER, whose mounts are its creds volume, /var/run/docker.sock, the operator env file and three entrypoint scripts -- that state directory is not among them. Mounting it would be a runner-fleet recreate to gain nothing, because the socket it already mounts reaches the same daemon the host-side pass reads. Same daemon, same answer. If the socket is unreachable the collector exits 4 (fail-loud, OMN-15466) and no PR is opened. WHY NOT A PR EVERY RUN. `lane_census_refresh_decision.py` is the pure rule and it says no most of the time. Four unconditional PRs a day is how an automation earns itself an exemption. It refreshes when the committed census is unreadable, when `alert_key` shows the lane topology moved, or at 3 days -- well inside the gate's 7-day limit so the PR has days to land rather than racing the deadline. Two guards come first and both protect the committed state: a malformed candidate is an ERROR, never a refresh, and a candidate not newer than the committed one is always a no-op, so a skewed clock cannot manufacture the staleness this leg exists to prevent. 24 tests. The anti-churn one walks the clock across two days of scheduled runs against an unchanged fleet and fails if any of them would have opened a PR. Two incident replay cases, both real captured bytes rather than reconstructions, because the coverage gate's default-deny is right to demand them of new enforcement: - the actual stale census, read out of the git object store at 2e4eec0, driven through the real decision at 2026-09-17T10:07Z -- the instant the gate went red -- and required to say REFRESH, with a companion at day one required to say nothing. - the drop-in as it was ACTUALLY INSTALLED on .201, scp'd off the host while it was still the pre-fix copy. Its single ExecStart names the collector with no output destination and no redirect, and systemd runs execve rather than a shell so a redirect could never have worked there. That is the false_green: the unit reported SUCCESS every hour precisely because the census pass wrote nothing and so had nothing to fail. Claude-Session: https://claude.ai/code/session_01Mg3nhbHwH7a3UoKLhRMFKk * test(OMN-18606): prove the writer-App path from a fixture, and keep the replay hermetic The replay's collector drive shelled lane-census-check.sh with a real PATH. Trusted CI is self-hosted ON the lab host, so that test would have inventoried the live .201 docker daemon from a unit test. PATH is now an empty directory: the argument loop still runs first, so exit 2 still discriminates the pre-fix 'Unknown argument: --snapshot' refusal, and nothing is collected. Five fixture-driven assertions on the writer-App PR path, which cannot be exercised without the host-201 runner and would otherwise be taken on trust: the App token is minted with no GITHUB_TOKEN fallback, the checkout carries it (a GITHUB_TOKEN extraheader would override a token in the remote URL and the bump PR would get no CI), the commit is attributed to the App it authenticates as, the title carries the prefix the ticket gate exempts, auto-merge is armed, and the only staged path is the census file. The end-to-end drives the real decision CLI over the real committed census and a fixture candidate instead of the lab host, asserting both directions from one pair of files: forced at zero days it refreshes, at the 3-day default it stays quiet. * test(OMN-18606): classify the new verify job and the new branch pusher Two repo invariants caught the leg in CI, both correctly, and both are the kind that must move in the same PR as the thing they govern. test_no_other_job_in_the_repo_uses_the_verify_label: the `omnibase-verify` + `host-201` label set is a closed enumeration, because a job added to it without a decision reintroduces starvation on a small pool. `refresh` is added as NEW_VERIFY_JOBS rather than folded into MOVED_JOBS: that tuple is the record of two specific decisions (OMN-18408 and its OMN-18602 follow-up), and adding a job to it would quietly rewrite what those decisions covered. It meets the bar OMN-18602 settled the label's meaning on -- the job READS the lane and never mutates it; the only thing it writes is a branch in this repo. And it needs the host label more sharply than the ten read-only probes do: a census collected against the wrong daemon is not an outage, it is a wrong answer committed as the documented lane topology. The `omnibase-ci` pool cannot serve it at all, because 60 of its 68 runners carry no host label (read live from the org runner census), so placement there is unpinned by construction. test_every_git_push_workflow_is_classified: the leg is a real branch pusher and is classified as one, not exempted. The tag-only exemptions do not apply -- it pushes a commit, and a commit can carry a trailer. The push identity is load-bearing rather than cosmetic here: a bump PR whose CI never runs cannot clear the staleness gate the leg exists to clear. Verified by running all 88 tests/ci files that read the workflows directory: 1439 passed.
7 tasks done
jonahgabriel
added a commit
that referenced
this pull request
Sep 24, 2026
…d exempts an inert version bump (#4057) * fix(OMN-19375): the rebuild classifier counts all installed source and exempts an inert version bump Two errors in the runtime-affecting predicate the rebuild trigger and the release train share, one in each direction. Under-count (OMN-19378). The canonical deploy-gate list names fixed subtrees. OMN-19383 added src/omnimarket/events/**, but the list still misses models/, enums/, adapters/, delegation/, routing/ and configs/: 939 of 4393 files under src/omnimarket and 1162 of 3322 under src/omnibase_infra before OMN-19383. Handler fan-in is the same as events/ (models/ 25 handler importers, enums/ 19, inference/ 38, routing/ 6). The lane installs both trees whole, so both are now lane state. omnimarket#2817 (delegation/, merged as No rebuild) is the measured case. Replayed over the last 60 dev merges: +9 omnimarket rebuilds, +1 omnibase_infra. Over-count (OMN-19375). omnimarket's post-release bot PR changes only [project].version and its own uv.lock entry, and each one rebuilt the dev lane (jobs 0805d076, e4d36317, ff4dc5de). omnimarket's version string is inert on the lane: it installs --no-deps from the staged tree (file:// direct_url on the running container), __version__ is a literal 0.1.0, and the one reader of the distribution version has no caller. A root manifest change that is only that package's own version is no longer lane state. omnibase-infra is not exempt because its runtime reads its own version. The reusable workflow checks out the merged commit and its parent and passes --source-checkout; the train reads the same pair from its clone, so the walk and the trigger agree. Every read failure keeps the manifest runtime. Live replay with the real canonical validator: the three bump commits read No rebuild; #2813, #2817 and all ten AC7 runtime PRs read runtime; the real dependency bump #2691 reads runtime. Onex-Lane: classifier-fix Onex-Session: 9e9904cc395d4ded885852026251341d * chore(OMN-19375): fresh non-draft head to clear the draft-era deploy-gate row Onex-Lane: classifier-fix Onex-Session: 9e9904cc395d4ded885852026251341d --------- Co-authored-by: onexbot-occ-writer[bot] <307849072+onexbot-occ-writer[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The lane-census snapshot (
deploy/lane-census/census-snapshot.json) was 9 daysstale (
emitted_at: 2026-07-29T22:26:53Z), failingLane Census Staleness + E-5 Env Drift (OMN-13034)on every PR in the repo. This PR regenerates itusing the documented procedure from
scripts/check_lane_census_age.py's ownerror message:
Run read-only on
.201(LANE_CENSUS_HOSTpinned to the FQDN the systemdtimer normally injects,
--dry-runso no bus event is published — this PRonly commits the JSON, it does not fire a duplicate drift ticket):
Live drift confirmed, not just staleness
The fresh snapshot (
emitted_at: 2026-08-08T19:39:02Z) shows the drift isreal and has grown since 2026-07-29 (10 -> 11 findings): prod is down all
5 required containers (
runtime-worker,agent-actions-consumer,skill-lifecycle-consumer,intelligence-api,contract-resolver),stability-test is down the same 4 plus a failed
forward-migrationone-shot(exited 46h ago), and dev carries one manifest-undeclared container. This PR
only refreshes the staleness signal to unblock the repo-wide gate — it does
NOT remediate the drift itself. Filing that as a follow-up ticket next
(dedupe-checked: no open PR/ticket found for this exact drift set as of
2026-08-08).
Verify
Pre-push governed selector escalated to the full suite (shared/config file):
23168 passed, 40 skipped in 543.25s.OMN-13034
Node-Migration-Source-Ref: dev
Evidence-Ticket: OMN-13034
Evidence-Source: OCC#6213