Venue pipeline implementation and audit

Status: Active Last reviewed: 2026-09-06

The owner requested research, planning, implementation and an audit for each area, with the venue pipeline completed before inspecting the rest of the backend. This record tracks source changes and their evidence; deployment and live data verification are separate outcomes.

V1 — Intake identity, adoption and edit authority

Mode: implementation. Starting point: 5febdb83, isolated branch codex/venue-pipeline-20260906.

Research found three independent boundary failures: picker-supplied fields could be stored as Naver observations; ingestion could collapse nearby or indexed resources; and a successful adoption could lose its continuation when the picker unmounted. Edit authority also accepted incomplete owner claims, and a facility type correction cleared a venue's operating state.

The plan preserves current contracts and uses the existing venue, observation, correction and mutation mechanisms. Search identity annotation is also an intake boundary: an annotated ID can skip adoption, so it must enforce the same identity and availability checks. Provider failure remains an error, with directory results still available through their independent query:

Part	Implementation boundary	Acceptance evidence
A	Adoption RPC and attachment validation	Caller fields and legacy picker markers cannot establish provider evidence; genuine source records still can. Existing venue deduplication is checked against identity.
B	Picker mutation completion and result correlation	Successful adoption survives overlay unmount; overlapping requests resolve independently; stale results cannot replace the current pick.
C	Ingest resource identity, raw evidence and display-name cleanup	Same-cell facilities and indexed courts remain distinct; raw provider IDs/names/pins survive; legacy re-ingest is idempotent; ambiguous identities are held. The routine reset path cannot delete records.
D	Correction application and permission projection	Incomplete/future owner claims cannot review edits; owner authority is venue-scoped; changing a type cannot close or reopen a venue; explicit approved closure/reopening still works.
E	Search completion and existing-venue annotation	A provider outage or exhausted budget remains distinguishable from zero matches; co-located indexed facilities are not deduplicated by coordinates alone; only unambiguous open matches carry a canonical ID.

Parts A–C/E have independent implementation owners. The integration owner handles part D, database fixtures, documentation, generated types and combined checks. SQL definitions are split across migrations 00603–00605; app edits use existing ports. Every implementation receives a review by someone other than its author.

Allowed scope is the venue write/read paths above and their tests. Other backend domains, live cohort refreshes and release operations are outside V1. Legacy business records are not rewritten to make a test pass. The source clone uses its own dependencies; database proof uses a separate sanitized database cloned from the prior venue test fixture, without resetting the shared local database.

Verification proceeds from regression fixtures to focused app/script tests, SQL role and invariant tests, real PostgREST checks where contracts change, strict lint and the repository yarn check. Review findings must be resolved and their affected checks rerun before this slice is accepted.

Subsequent venue slices

V2 connects missing-venue submissions, individual-court changes, corrections, closure, relocation and reopening to a tracked review case, contributor history and decision notifications. Court identity/history and concurrent decisions are part of that acceptance boundary.

V3 replaces source-count backlog work with scheduled freshness and durable fetch/persist/reconcile retries, preserving the last accepted facts during provider failures.

V4 completes owner contribution integration with approved claims, scope, revocation and transfer, while keeping certification distinct from community information reliability.

The V4 ownership audit records server implementation, independent findings, actual SQL/HTTP verification and local app integration. The ownership workflow defines application review, transfer, departure, privacy and export behavior.

Each slice starts with a refreshed research and implementation contract and ends with independent audit evidence. None is marked complete by this initial plan.

Backend sequence after venues

Inspect identity/permissions/privacy, payments/dues/refunds, sessions/capacity, clubs/membership, matches/ratings, notifications, social/media, and external weather/reference feeds. Cross-cutting review covers triggers, scheduled jobs, maintenance scripts, storage, offline replay and cache/user-visible outcomes. Existing audit logs are leads to recheck, not current runtime proof.

Verification record

V1 source implementation and verification are accepted. No V1 migration has been deployed and no source/cohort refresh has been applied by this work.

Independent review found and required fixes for retained permission grants, reused provider row IDs across picker mounts, duplicate completions within one picker, and caller IDs reserving canonical provider identities. The last issue also reaches the club court bridge, so acceptance covers that trigger path.

The recovered business-snapshot fixture lacked migrations 00599–00601, real auth.uid() helpers, the signup trigger and the surface catalog. It cannot be used alone as proof of the complete app contract. A separate schema-only local database now carries real authentication helpers, canonical public reference seeds, migrations 00599–00602 and no real users or venue history. The final V1 rehearsal passed 899 assertions across all 30 venue/court/ACL suites there. All test transactions rolled back; the fixture still has zero users, profiles, venues, observations and claims. Business-snapshot checks are recorded separately and do not imply the reviewed cohort migrations have been deployed.

The legacy service-only public_courts bridge and opaque historical maintenance keys retain their existing concurrency contract. The new shared intake lock covers authenticated adoption, authenticated club creation and versioned resource ingestion. The club bridge preserves the existing temporary-closure linking policy; V2 owns the explicit operating-state presentation and transitions. The revised search and ingest Edge entry points also bundle successfully with the locally installed Supabase Edge Runtime image (v1.74.0); this is a bundle check, not a deployment or live-provider result.

A separate synthetic PostgREST database passed 19 authenticated HTTP checks, including simultaneous picker requests and simultaneous adoption/ingestion converging on one venue UUID. Ordinary users cannot ingest provider evidence or review another venue's submissions. The final migrations were independently accepted after their audit fixes. Focused adoption/correlation checks passed 109 tests; source/search/script checks passed 46 tests. Repository strict lint, PI schema lint, agent-rule lint and file-size checks passed. The combined repository yarn check passed: 5,482 tests across 379 Jest suites, plus 117 script tests (two environment-gated tests skipped). The broader run caught one obsolete HTTP mock without headers; the fixture now models a real response and the affected 29 tests also pass independently.

The public generated database types were regenerated from this final HTTP fixture with Supabase CLI 2.105.0. Its fixture omits the managed GraphQL schema; the existing graphql_public type and constant blocks were retained unchanged. Local receipts live under .audit/venue-pipeline-v1-20260906/.

V2 — Contribution and court contract

Research confirms that corrections require an existing venue, reports have no usable review outcome, and a roster correction deletes/recreates court rows. The report table also still grants authenticated INSERT, bypassing the RPC's quota and server-controlled timestamps. This slice adds a receipt above the existing correction engine and closes these write paths.

The contribution envelope has an authenticated author, client request UUID, kind, optional target venue, proposed payload, evidence, a server-captured baseline, state, decision explanation, resulting venue/correction IDs and timestamps. Repeating the same request and payload returns the existing receipt; reusing its key for different content is an error. Evidence consists of a bounded observation date, optional public reference URL and firsthand note. Notes and author linkage remain visible only to the author and authorized reviewers. Purpose metadata accompanies the schema. Raw client writes cannot set decisions, timestamps or authorship.

The first implementation supports these kinds:

Kind	Proposal and effect after acceptance
new_venue	Name, address, Korea pin and venue kind. Remains outside the public directory while pending. A reviewed identity either links to one matching venue or creates a manually sourced venue; it grants no owner certification.
facts	A bounded set of existing field/value corrections, validated and applied atomically through the established correction engine.
courts	Explicit add, update and retire operations. Updates address a court UUID belonging to the target venue; unspecified fields and all historical links survive.
lifecycle	Temporary closure, permanent closure, relocation or reopening. A reviewed transition preserves the old venue's historical identity; relocation can reference a distinct existing destination.
report	A reported problem and evidence for investigation; accepting the report alone never manufactures a replacement fact or closes a venue.

New submissions enter pending. Reviewers can accept, reject or request more information with an explanation; authors can withdraw an undecided submission or provide a replacement linked to the prior receipt. Pending and decided history remains retrievable after app restart. A reviewer may accept one supported submission: there is no required second account. Review authority is rechecked at the decision transaction, using the verified-claim rule from V1; new-venue review requires platform staff.

Decisions lock the receipt and venue, then compare relevant current facts to the captured baseline. A conflicting change produces a visible superseded outcome without applying stale values. An unrelated refresh timestamp alone does not invalidate a proposal. Each accepted decision retains before/after evidence and linked correction IDs. Notifications use the existing signal mechanism; receipt state remains authoritative if notification delivery fails.

Court operations preserve UUIDs, non-edited metadata and parent/history links. Count remains derived from the non-retired roster and stays within the existing 1–40 contract. Ordinary account agreement cannot auto-approve inventory changes. Legacy anonymous roster replacement may initialize an empty roster; replacing an existing roster without court identities is rejected. Existing pending requests must pass these same guards when applied.

Implementation ownership is split between the contribution ledger/decisions, stable court backend, and feature submission/history/review surfaces. The integration owner supplies domain schemas, ports, adapters, hooks, generated types, role/concurrency verification and docs. Each owner reads the existing consumers before editing, and each implementation receives independent review.

Acceptance covers request replay and mismatched reuse, actual RLS roles, report write denial, quotas, one supported review, revoked/cross-venue authority, stale and concurrent decisions, atomic multi-field failure, preserved court IDs/metadata, recurring incidents, closure/reopening, receipt retrieval and user-visible errors. Persistent offline delivery and provider refresh are separate work; this slice does not claim either from an in-memory retry.

V2 implementation and independent findings

Migrations 00606–00610 implement the stable court operations, protected ledger, submission and decision transactions, paginated history and unresolved legacy report backfill. App domain schemas, repository ports, Supabase adapters, account-scoped queries and mutations connect the ledger to both mobile and web submission, history and review routes. Existing venue detail controls now stage one supported proposal with an observation date and evidence. Receipt history links to the current venue and any relocation destination by name.

The transaction design was checked against PostgreSQL's row and advisory locking contract and Supabase's function security guidance. Receipt and ordered venue locks protect concurrent decisions; the shared intake lock converges independently accepted duplicate venue submissions. Private functions and raw tables have no client write grants. Revocation is checked in the decision transaction and private receipt reads.

Independent implementation and integration review found and closed these failures before acceptance:

• An accepted duplicate identity could overwrite canonical address or pin without a facts baseline. Reviewed identity now lives in a separate nested source proof; deduplication leaves existing canonical facts intact. Public identity evidence survives deletion of the contributor's private account history and cannot grant an owner badge.
• Older matching corrections could defeat a newer explicit reviewer decision. Accepted facts now assert the actual applied values and resolver row count; their linked correction IDs suppress redundant per-field notifications.
• Stale outcomes left authors without a recovery route. An author can replace an unreplaced stale receipt using current facts, preserving the original decision and its explanation.
• Unicode text accepted by PostgreSQL could fail app receipt parsing and hide history. Text bounds count code points on both sides, and SQL trimming matches JavaScript trimming. The installed Zod 4.3.6 intersection behavior also lost nested strict-key errors; explicit discriminated branches preserve validation without upgrading the dependency. This follows the documented object extension guidance.
• A Korean observation date entered before 09:00 serialized into the future. Calendar-day parsing now uses the Korean day boundary, including leap dates and the supported 1900 lower limit. Observation instants use the established domain Date contract; adapters validate and serialize ISO wire values. Pagination retains its raw timestamp token so PostgreSQL microseconds survive.
• Late request completions could navigate after unmount or account change; geocoding could replace a manually adjusted pin. Session, mount and request generation checks fence those completions.
• Replacement editors could show current canonical values while submitting prior proposed values. Controls now seed from the proposal while retaining a fresh baseline, and staged confirmations follow subsequent control edits.

The final synthetic PostgREST rehearsal passed 86 authenticated HTTP checks, including concurrent request replay, current and revoked owner authority, stale recovery, recurring reports, closure/reopening, preserved court identity, duplicate new venue decisions and exact timestamp/UUID pagination. Actual responses and migration hashes are checked into the app wire-contract fixture; all identities and notes are synthetic. Local full receipts live under .audit/venue-pipeline-v2-20260906/.

The combined SQL rehearsal passed 1,155 assertions across 33 venue/court/ACL suites with unchanged migration hashes. Three legacy fixtures now assert that matching court inventory requests remain pending, create no court/count changes and send no approval signal. The separate supported amenity corroboration tests retain coverage of notifications to both legacy submitters. All transactions rolled back in the sanitized fixture.

The final repository yarn check passed: 5,588 tests across 388 Jest suites, plus 117 script tests (two environment-gated tests skipped). Strict repository lint passed. Independent acceptance also passed 63 feature tests and 29 schema/mapper boundary checks against unchanged source hashes. The first full platform typecheck caught an invalid error-color token that feature-only typechecks did not see; the fix uses the existing shared theme token. The web build also exposed a missing shared error-normalizer export in the web Sentry module: query and mutation error handlers could fail while handling an API error. Both platforms now export the same existing normalizer, with direct platform-export regression checks. The production web build passes with the missing-export warning resolved, using synthetic local-only client configuration; it is not evidence of a working hosted service. An existing web location shim still lacks getLastKnownPositionAsync, affecting optional browse distances; that build warning is recorded separately from contribution validation. Mobile dependency preflight reports existing Expo/package version drift; this slice changes no dependencies and does not claim native release readiness. Browser visual QA, hosted migration application, real provider refreshes, durable offline drafts and notification delivery are separate boundaries.

V3A — Durable Kakao refresh jobs

Research found that the nightly worker selected only venues below two source families, skipped every existing Kakao observation, and counted a search as one call even when it retried three times. Observation recording and fact resolution used separate transactions; a crash between them could permanently skip the unfinished work. Provider errors could also become empty successful searches.

The replacement preserves the cron/manual endpoint and existing source authority. Protected jobs schedule open, usable Korean venue identities against a 30-day evidence target, regardless of source count. A no-match, hold or attempted request does not make old evidence fresh. Operational reads expose overdue, held, retry and pending-application work. Sixty request reservations per Korean day cannot promise monthly coverage of the historical 3,484-venue snapshot; it permits at most 1,800 dispatches in 30 days before retries.

Each provider request needs a current lease and a new durable reservation. Every reservation replay refuses another dispatch, including a retry after a lost response. The bounded helper makes one request, blocks redirects, preserves raw provider identity and distinguishes complete no-match, ambiguity, configuration, HTTP, malformed-body and transport outcomes. Results are saved before application. A separate current lease applies a saved match; application retries consume no provider budget. This is a reservation bound and cooperating-worker protocol, not an exactly-once guarantee for an external side effect.

SQL application compares captured identity, lifecycle, known provider IDs and the target source revision under the venue lock, reruns the existing attachment guard, and requires exactly one resolver result. Failed application rolls back public source/fact changes while retaining its retry receipt. The existing human, audit and leading Naver authority and stable court history remain protected. Richer old source metadata outside the fetched projection holds for review rather than being silently erased or restamped. A miss never closes a venue or certifies an owner. Other provider and maintenance writers remain separate V3B work.

The design follows PostgreSQL's queue locking guidance and the Kakao Local response contract. Independent review reproduced a worker deadline overrun after a slow, retried claim; a check after claiming now leaves insufficient-time work recoverable. SQL review also required conflict-safe first seeding, NULL-safe resolver counts, reason-specific hold recovery and validation at the Korean day boundary. Claims skip a busy existing parent without declaring that venue removed. This also covers limit-one expired-dispatch recovery, which can otherwise hold earlier parents while scanning for eligible work.

The integrated Edge candidate passes 69 focused refresh/ingest tests and an independent 67-test provider/worker review. All 36 venue SQL suites pass, totaling 1,280 assertions including 125 new refresh assertions. A fresh synthetic database through 00615 passes 205 HTTP checks: role denial, first-seed overlap, reservation races, finish/apply replay, rollback on NULL resolution, stale identity, late results, both busy-parent claim paths and the shared 60-request budget. The actual worker calls real local PostgREST and SQL with only provider transport replaced by a synthetic response. No live Kakao request is part of this proof.

The production entrypoint bundles with Supabase Edge Runtime 1.74.0 from an isolated dependency mount. The generated public types come from the same accepted synthetic schema; existing GraphQL types remain unchanged. yarn check, strict lint, PI-schema, agent rules and stale-claim checks pass. The repository run includes 5,588 Jest tests in 388 suites and 166 passing script tests, with two existing environment skips. Receipts live under .audit/venue-pipeline-v3-20260906/. This slice is accepted in source; its hosted migrations and worker deployment remain separate. No live Kakao request was made.

V3B1 — Maintenance extraction and operational receipts

The maintenance audit reproduces 21 failures using actual modules and local fixtures. The first repair now binds Naver review/photo/blog metadata to the exact Place entity and its explicit relationships. Unpublished fields remain unknown; missing or conflicting attached entities hold that snapshot. An observed preview count does not pretend to be the complete provider inventory. Two saved HTML pages ground the graph shape; sanitized fixtures preserve venue identity and references without carrying reviewer identities. Thirty new tests and 16 independent probes cover the projector and the actual scraper's hold/retry branch. All 56 related canonical scraper tests pass; no live Naver page was fetched for this repair.

The same maintenance slice replaces first-key routing with one explicit operation, valid and distinct target IDs, the existing inventory prohibition, and bounded JSON input before service-client creation. Posting scripts use a shared receipt reader: exactly the transmitted row count must be acknowledged, redirects are blocked, response bytes/time are bounded, and unreadable or partial results stop the run. The shared emitter and all three direct posting loops use that contract. Primary RPC counts are validated before profile/name follow-ups; those stages accept valid zero-change results but reject null or impossible counts.

Independent review required fixes for error objects retaining invalid configuration text, caller arrays changing the expected count during an await, insufficient row validation, and downstream stages continuing after a short resolver result. The 53 focused operational tests exercise actual Edge and CLI functions with synthetic transport, including stalled incoming bodies, partial stages and failure to obtain a valid receipt. A separate independent run passes 72 tests, including 21 new boundary probes and actual client-to-handler/emitter-to-handler continuations. These overlapping runs are recorded separately rather than added together.

This extraction/receipt slice passes yarn check: 5,588 Jest tests in 388 suites and 227 script tests, with two existing environment skips. Strict lint, PI-schema, agent-rule and stale-claim checks pass. The request reader typechecks independently, and the actual enrichment entrypoint bundles with Supabase Edge Runtime 1.74.0. No SQL changed in this slice. Exact source hashes and independent receipts are under .audit/venue-pipeline-v3-20260906/maintenance/.

These are extraction and operational correctness repairs. Legacy live writes remain separate transactions; an error can follow an earlier committed stage. They do not provide durable capture, resumability, or multi-stage atomicity.

Separate source tracing found that generic observation replacement can erase omitted provider fields and restamp older facts as newly captured. The legacy coordinate route also accepts a scalar pin without captured provider evidence or a comparison against current canonical state. A proposed maintenance application contract requires explicit field coverage, captured timestamps, source and canonical revision checks, protected authority and an atomic per-target receipt. The following V3B2 slice implements that SQL boundary and separate ingestion receipts. Collector response validation and actual prepare/capture/resume integration remain subsequent repairs.

The existing Naver corpus gate remains closed at 2,324/2,325; none of this work shrinks that cohort or authorizes its pending metadata refresh. Owner onboarding and other backend pipelines remain separate planned areas.

The official government dataset documentation confirms the raw hour fields, reference date, page limit and provider result codes. It does not establish the nested JSON envelope expected by the two conflicting importers. One bounded one-row research request timed out without a response; it provides no evidence of current source emptiness, completeness or wire shape.

V3B2 — Captured hours application and ingestion outcomes

Migrations 00616–00620 add a protected maintenance ledger, preparation before fetch, immutable raw capture, fenced application and operational reads. The initial contract handles the three government hours paths on existing venues. The server independently reconstructs them from raw strings and coverage; convenience previews never become authority. Name/address keys remain derived identities, and a missing government record cannot claim absence. Unreported provider fields, source row identity, old observation times, and stronger canonical facts survive a partial update. New field lineage records capture time separately from the source reference date and legacy unknown timestamps.

Identity, lifecycle, provider-reference and source-revision changes supersede prepared work. Savepoints roll back public facts, source rows and field provenance together on failure while retaining the capture and failed attempt. Retries require a current lease and use the saved capture without refetching. Legacy write RPCs and ingestion cannot overwrite enrolled venues; reviewed private delegates retain existing correction, quarantine and Kakao refresh behavior. Existing privileged direct table DML remains a separate boundary, and no hosted migrations or collector activation occurred.

Independent review reproduced and closed future-dated source acceptance, legal long identity receipt overflows and failed-result retention after rollback. Preparation now has an explicit 512-KiB receipt budget for its maximum 50 targets; ordinary receipts and raw captures retain their 64-KiB limits. Oversized legacy baselines become compact held targets. Detailed history includes snapshots and needs separate transport bounds; these per-record limits do not promise a bounded aggregate read response. Full compatibility tests also preserved database-owner SQL access under existing EXECUTE permissions while keeping enrollment guards unconditional. PostgreSQL's own UUID parser prevents alternate valid UUID spellings from bypassing those guards.

The pure government parser preserves raw values, presence and reference dates. It accepts whole decimal Korean coordinates, complete valid hour pairs and supported clock boundaries. Partial, malformed or ambiguous fields hold the row. Rest-day wording does not invent closed weekdays; fee text stays unapplied. Twenty-eight permanent tests and eight independent parser tests pass. A separate 116-assertion run feeds 29 actual producer outputs into SQL reconstruction. These are source-record checks, not proof of the live provider's envelope or a complete collection.

The ingestion writer now snapshots batch layout, validates acknowledgements and stops after a short or uncertain result. It never retries individual rows after a failed batch. Confirmed counts measure processed row operations, not newly created venues. Separate inventory-read failures retain those confirmed counts. Requested source failures make the handler fail even during dry-run; independently completed writes stay confirmed. Setup, partial and uncertain outcomes remain distinguishable with constant error codes. The independent run passes 36 actual-module tests, including 13 additional boundary cases. Internally swallowed collector failures and missing transport deadlines remain subsequent work; this repair does not claim atomicity across batches or durable client recovery.

The canonical SQL run passes 1,504 assertions across 40 venue/court/access suites. After moving the legacy resolver, three source-order checks follow its guarded public entrypoint and sealed implementation; the prior refresh fault-injection test targets that implementation and retains its rollback assertions. The final 121-check HTTP run uses a fresh local database and actual PostgREST roles. It covers concurrent duplicate application, enrollment racing a legacy writer, two competing captures, lease expiry, source preservation, rollback/retry, history pagination and maximum-size preparation. No real provider account or venue evidence is used in those fixtures.

Generated public types come from that schema: seven new RPCs, with existing public contracts and GraphQL definitions unchanged. The ingestion entrypoint bundles under Supabase Edge Runtime 1.74.0, and its writer passes strict TypeScript against the installed Supabase SDK. yarn check passes with 5,588 Jest tests in 388 suites and 278 script tests, plus two existing environment skips. Strict lint, PI-schema, agent-rule and stale-claim checks pass. Source acceptance is recorded with exact hashes under .audit/venue-pipeline-v3-20260906/maintenance/.

V3B3 adds the bounded transport below; recoverable client orchestration, verified provider envelopes and actual collector cutover remain subsequent work. Owner claims remain V4; the wider backend queue is planned after venues. The separate Naver closeout gate remains 2,324/2,325.

V3B3A — Bounded maintenance endpoint and client

Research traced all seven maintenance RPCs and their consumers before implementation. The dedicated endpoint validates exact named parameters, request/response identity, original timestamp precision, operation byte budgets and complete streamed responses. Private-token authentication precedes database access; only this function receives a custom-auth configuration entry. The client sends saved serialized bytes once, has no automatic retry, and distinguishes failed reads, definite rejection and unknown mutation completion. The shared pure contracts keep the server and client aligned.

Independent review reproduced two gaps: malformed error fields could imply false certainty, and an applied receipt could contradict rolled-back stages. The fixes require typed, operation-bound failures and the actual successful, no-op and savepoint outcomes from migration 00619. Source-only changes remain valid when stronger authority retains the canonical hours. All 78 author and independent tests pass in canonical source paths; tests use the existing fixture runtime to support the repository's Node 20/22 test matrix. The operator client itself requires Node 22.22 or newer to load shared TypeScript modules.

The isolated HTTP rehearsal passes 15 checks connecting the actual client and endpoint to local PostgREST and synthetic SQL data. It exercises all seven routes, rejects changed content under a reused request UUID, retains exact pagination cursors and deliberately loses a response after application commits. Replaying that original request recovers the committed receipt, with exactly one database attempt and untouched unrelated source fields. The local gateway is a test bridge; this is not proof of hosted gateway configuration.

Exact-source acceptance, focused test logs and local HTTP receipts are retained under .audit/venue-pipeline-v3-20260906/maintenance/. Repository-wide yarn check passes 5,588 Jest tests in 388 suites and 356 script tests, with two existing skips. Strict lint, agent rules, PI migration checks and stale-claim checks pass. The Edge function also typechecks and bundles in the local Supabase runtime (133,266 bytes). No migration, hosted data, provider collection, existing maintenance caller or owner certification is changed by this transport slice. Journal and operator-runner integration remain V3B3B; the government-envelope and Naver completeness gates remain closed.

V3B3B — Recoverable maintenance commands

The operator now persists immutable request bytes, bound successful responses and a verified event chain before progressing to another action. Atomic publication, file identity checks and a kernel-held lock protect recovery on the supported Linux/ext4 runtime. Interrupted original applications are reconciled before fresh claims; a saved success requires no network replay. Corrupt or incomplete state stops dispatch. This provides process-interruption recovery, not a guarantee against disk loss or deliberate rewriting by the same operating-system account.

yarn venue:maintenance exposes explicit prepare, refusal, get, list, resume and apply commands. The immutable run scope, ten-call/90-second ceiling, exact list cursors and lease checks bound each invocation. List inspection cannot widen application scope. Generic resume creates no new work. Private configuration comes only from the supplied environment, and credential values are absent from journal files and summaries. The operator workflow documents setup and outcomes.

Independent review closed stale summary ordering, expired-claim display and terminal application demotion by a late old claim response. A separate clock-rollback regression proved that an already-recorded expired claim could be selected again; the repaired selection permanently excludes that exact claim from fresh work. Recovery of an original unresolved application remains possible after expiry. A normalized stale-lease rejection is retained separately from a successful receipt and permits a later explicit application to obtain a fresh claim.

All 104 canonical journal/runner regression tests pass on Node 22.22 and the repository's Node 20 test line. The latter uses a test-only loader restricted to seven existing maintenance TypeScript files; operator execution remains Node 22.22 or newer without a runtime compiler. An independent promotion audit verifies all twelve runtime modules, thirteen suites and the loader boundary. Repository yarn check passes 5,588 Jest tests in 388 suites and 460 script tests, with two existing environment skips. Strict lint, agent rules, PI-schema checks and stale-claim verification also pass.

The final canonical-source rehearsal passes 22 checks through actual child processes, the shared endpoint/client and a new local PostgREST database. SIGKILL at three request publication boundaries and a dropped committed reply recover the original application; the database contains exactly four applications for four selected targets. Unrelated source fields survive, another resume sends nothing, and list continuation retains scope and timestamp precision. The synthetic gateway is a test bridge, not hosted configuration proof. Exact source hashes and receipts are retained under .audit/venue-pipeline-v3-20260906/maintenance/runner-promotion/ and runner-rehearsal/.

No existing collector or scheduler is switched by this slice. Government wire-envelope verification and collection/capture integration remain required; the Naver 2,324/2,325 gate stays closed. Owner claims, complete own-claim export and the wider backend audit continue as separate areas of work.