Perforce / P4 Code Review
Automatic submitted indexing worker
openreview p4 watch discovers the latest visible submitted changelist across the selected project's native positive views using p4 changes -s submitted -m 1. It verifies the configured SSL server ID and bot identity before/after discovery, pins native fstat metadata at that submitted change, respects ordered project exclusions and checks native views again. Only metadata is uploaded; hosted indexing independently reads pinned source, verifies digests and reuses unchanged file caches. No checkout, shelf, submit or native approval is changed.
First log in with an existing workspace administrator API key using openreview login. Keep the key in the owner-only CLI configuration. Set P4USER/P4PASSWD using your secret manager to the dedicated bot and existing ticket, and establish SSL trust manually through your operator. Do not put tickets in command arguments. Authorize the Code Review hostname in the worker's SCM_ALLOWED_HOSTS. Then run:
openreview p4 watch --server ssl:HOST:1666 --server-id NATIVE_SERVER_ID \
--url https://code-review.example --project PROJECT \
--repository OPENREVIEW_REPOSITORY_ID --interval 300 --once
Replace the server identity with the value verified from your native server and use the selected repository ID from Settings → Code providers. Remove --once and run under your process supervisor for continuous operation. Intervals are 60–3600 seconds, default five minutes. Busy hosted indexes are skipped; unchanged ready inventories are not uploaded. Every iteration checks current administrator/connection access before native reads. Three consecutive failures stop the worker visibly; restore access/trust/tickets or fix the reported dashboard indexing failure before restarting. SIGINT/SIGTERM stop after the current bounded read operation. If the process stops, submitted indexing stops; this release does not claim a hosted worker heartbeat. Native protections can hide files/changes and their unknown coverage remains explicit.
The authenticated no-store GET /api/p4/index?repositoryId=… provides current project/instance/index status to this worker; viewer, other-workspace, disconnected and suspended access fail closed. Existing POST metadata upload remains compatible. Baselines cannot move to a lower submitted change or silently switch native server IDs. A server migration requires explicit operator reconnection/reselection.
A failed hosted index stops watcher retries rather than silently creating fresh jobs each cycle. Inspect the dashboard error, restore the underlying native access/source condition, and perform an explicit openreview p4 index / openreview p4 upload retry before resuming continuous watching.
A successfully completed authorized baseline automatically replaces the generation of already enabled review polling, clears stale leases/cursors, and cancels unfinished automatic reviews at the old baseline. Completed history and separately requested manual runs remain preserved; manual workers still enforce their original baseline. Disabled polling is never enabled by an upload or watcher. Changed connection credentials or a revoked polling administrator cannot authorize adoption; an administrator must explicitly restart polling with current access. This supersedes older instructions requiring a manual polling restart after every baseline refresh.
Contract tests cover discovery/metadata-only transport, unchanged/busy skips, failed authorizations and native diagnostics, atomic baseline adoption, stale-worker cancellation, disabled-poll preservation and backwards/server-mismatch rejection. The existing native acceptance server also passed real submitted discovery/fstat with zero source-body reads or inference. A temporary continuous native CLI process now passed changed submit → hosted incremental index → already enabled polling baseline adoption → automatic review/publication. Persistent supervisor hosting and the remaining recovery matrix still require acceptance; no native automatic approval is claimed. See incremental acceptance.
Settings → Code providers accepts an HTTPS P4 Code Review (formerly Swarm) URL and a dedicated bot’s P4 login ticket. The operator must allow that host in SCM_ALLOWED_HOSTS on both web and Convex deployments. The credential is JSON with exactly username and ticket; no password field is accepted. Obtain the ticket using p4 -p <server> -u <bot> login -p and manage its expiry/revocation in P4. Do not place tickets in URLs, logs, or source control.
Connection setup verifies the native project inventory before saving encrypted credentials. Workspace administrators can inspect current project IDs, branch IDs and depot views, then connect selected projects. Selection re-fetches the native catalog and rejects unavailable IDs. Each project creates a workspace repository scope and a team keyed by provider, instance and native project ID; existing assignments and settings survive repeated selection. Team access, inherited settings and repository rules use the existing workspace controls. Native P4 memberships are not imported. Disconnect removes the stored credential. Project access is not mapped to a fake Git remote or default branch, and connected projects remain disabled for generic Git automation. The separate native polling control is opt-in. Generic enable/index controls are rejected because native depot indexing requires an explicit submitted baseline; manual submitted-revision uploads and archived-shelf reviews are supported as described below. Repository settings remain editable without enabling reviews. This catalog does not claim initial indexing is complete. Configure P4 protections and private project membership to restrict the bot to intended sources.
Each accessible project offers Inspect native reviews with author, description, native state, shelved/submitted status and update time. Older/latest links use native review cursors. The authenticated providerJobs.p4Reviews action rechecks workspace admin access, active connection, project access and branch identity on each request. Short pages retain their cursor; empty pages with a cursor and cursors that could skip returned IDs fail visibly. Inspection does not enqueue model calls or enable automatic review processing.
src/perforce.ts also reads review pages, archived shelf manifests, digest-checked source and complete revision-pinned file diffs. Pending reviews without an archived changelist fail visibly. Native inventories can hide files according to server protections; their unknown coverage is retained. Truncated inventories/diffs, duplicate identities, invalid views, mismatched content origins/digests, and revision changes are rejected.
Native branch views are evaluated in order, separately for each participating branch. Snapshot identities include the selected branch IDs and ordered views, so changes in branch scope invalidate publication.
The adapter can publish revision-bound inline findings followed by a summary. It validates native diff lines, publisher identity, review version, depot file and right-side anchor. Comment retrieval includes archived comments and fails closed on incomplete pagination (100 per page, at most 5,000 scanned). A retry resumes accepted inline writes after a lost response; archived publications are not resurrected. The native API has no atomic idempotency guarantee: hosted manual dispatch uses durable worker leases and rechecks authorization before each native publication operation. External acceptance must still verify native retry behavior.
Native manual review, review polling, personally scoped follow-ups, local P4 bridge launch and opt-in runtime validation are implemented in the sections below. Automatic submitted-depot inventory and authorized cross-repository context are implemented with the native evidence below. Provider approval remains incomplete. Agent completion and the full OS/agent matrix remain unverified. Native acceptance evidence and remaining limits are recorded at the end of this document. Live acceptance requires a reachable P4 Server and P4 Code Review instance, a bot ticket and a disposable project with archived shelved reviews. Contract checks do not establish external acceptance.
Primary API references: authentication and requests, project access and depot views, revision-specific files and diffs.
Native submitted-revision index
The local CLI now builds the shared symbol/import graph from all eligible files in the selected project's depot views:
openreview p4 index --server ssl:p4.example:1666 --server-id main \
--url https://code-review.example --project payments --change 42 \
--output payments-index.json
Set P4USER and P4PASSWD to the dedicated read-only bot identity and ticket. Allow the Code Review host through SCM_ALLOWED_HOSTS. Install the official P4 CLI, establish the server's SSL trust independently, and obtain the native server ID from your administrator. The configured P4 Server must be the one backing that Code Review instance. No password or ticket is put in command arguments or output; the command never changes SSL trust, client workspaces, shelves, depot files or changelists. Local P4 config and cached tickets are isolated from the invocation so another checkout's configuration or credential cannot silently authorize it.
The command verifies the actual server/user and a submitted changelist, retrieves revision-pinned fstat manifests through fixed CLI arguments, honors project exclusions and explicit re-inclusions, and reads each eligible file at its native revision with keyword expansion disabled. Native print bytes must be valid UTF-8 and match the depot digest; unsupported encoding or client conversion fails visibly. Every file must match the recorded native MD5 and size before the existing shared indexer receives it. The Code Review project is fetched again before saving to reject changed views. The output has owner-only permissions and refuses to overwrite an existing file.
The artifact retains native server, project, changelist, manifest revision, skipped-file reasons and coverage limitations. Paths are depot-relative to preserve depot identity and allow import resolution. Server protections can hide files; project-specific ignore files are not applied automatically. Current bounds are 100 include patterns, 10,000 inventory records, 200 KB per source file, 20 MB of source, 8 MB per metadata response and 60 seconds per native command. Metadata replacement characters, missing digests, unexpected encodings or changed source fail visibly. This local command does not activate automatic reviews. Its metadata inventory can be uploaded for durable hosted indexing as described below; automatic depot polling and native acceptance remain incomplete.
Native references: tagged JSON and explicit authentication, revision-aware inventory, and pinned printing, line endings and keywords.
Native archived-shelf review
The CLI can now combine that submitted project baseline with an archived shelf and run the existing shared review engine:
openreview p4 review --server ssl:p4.example:1666 --server-id main \
--url https://code-review.example --project payments --change 42 \
--review 57 --mode standard --output payments-review.json
--change explicitly selects the submitted comparison/context baseline; --review is the native P4 Code Review review ID. It must be open with an archived pending shelf. Configure the existing LLM_* environment variables for inference. The command reads through the same bot identity and native CLI checks as indexing, preserves native revision identities rather than inventing Git SHAs, and overlays archived additions/edits/deletions on the baseline. Unchanged caller files participate in shared graph retrieval. Diff headers and right-side source are checked by the native adapter; left-side context must match the indexed baseline before inference. A missing readable baseline, changed views/revision/state or unmatched diff fails visibly.
Excluded changed sources are removed from the context instead of leaving stale baseline code, with coverage reasons recorded. Binary and secret files are not fetched as review source. The final native shelf is checked again after inference. Output is owner-only and refuses overwrites before making model calls; it records the native server/project/review/version/change, submitted comparison revision, findings, review score, diagnostics and model usage. It does not publish, approve, submit, change a workspace or modify a shelf. The chosen baseline is not claimed to be an automatically discovered common ancestor. Select the correct submitted baseline for the review's depot views.
This provides tested native shelf ingestion and shared engine execution, not the hosted application pipeline. Follow-ups, P4 bridge fixes and native live acceptance remain outstanding. Hosted dispatch/publication and optional durable native review polling are described below. Their contract checks do not establish live acceptance.
Manual hosted indexing
After connecting and selecting the native project in Settings → Code providers, create an OpenReview API key as a workspace administrator, use openreview login, then upload a newly generated native index artifact:
openreview p4 upload --input payments-index.json --repository <OpenReview-repository-ID>
Find the OpenReview repository ID in GET /api/repositories using that API key; it is distinct from the native P4 project ID. The upload uses the existing CLI login origin and revocable API key. It sends only the Code Review instance and canonical native metadata inventory, including project views, submitted changelist, file revisions, sizes and digests. Local indexed source bodies, ticket, symbols and review findings are not uploaded. Old artifacts without the new inventory and codeReviewInstance fields must be regenerated. The API endpoint is POST /api/p4/index; it returns HTTP 202 with jobId, revision and eligible file total. Completion is asynchronous. Inspect indexing status, skipped paths, retries and indexed revision using the existing repository settings detail.
The hosted bot must reach the Code Review HTTPS instance and have read access to the pinned files. The backend rechecks current admin access, connection/instance/project identity and current native project views, recomputes the inventory revision, then independently retrieves every new source at #<file-revision> through the native API. File metadata, content origin, byte size, MD5 and UTF-8 decoding must agree before the shared graph/chunk indexer stores it. Project scope is checked before/after source retrieval and before completion. Existing same-file revision caches can be reused. The manifest hash establishes identity, not the completeness or authenticity of an operator-enumerated depot inventory: the administrator is trusted to select the correct backing server and submitted baseline. Protections can hide inventory, and project ignore files are not applied automatically.
Durable jobs use the existing 20-file batch, retry and recovery system, with atomic batch leases preventing overlapping retry/recovery writes. Each mutation checks the current requesting admin and the active original provider connection/credential generation. Removed membership, disconnected/suspended access or replaced credentials stop future writes and completion. Dirty local workspaces are never changed by indexing. The CLI reads at most 40 MB of local index artifact. Upload bounds are 750 KB metadata, 8,000 records, 200 KB per source and 20 MB eligible source; exceeding a bound fails explicitly. The local native inventory ceiling remains 10,000 records. Manual indexing leaves automatic reviews disabled. It does not itself request a review, launch fixes, run checks or approve changes. A reachable real P4 installation remains required for live acceptance.
Hosted archived-shelf preparation
Completed native index jobs retain their canonical metadata manifest. The private p4ShelfJobs.prepare action loads only a completed current baseline and verified stored sources. It checks current requesting-admin access, active connection, original credential digest and exact indexed revision before loading files, and repeats these checks after native shelf ingestion. A new/restarted index, replaced source identity, changed credentials or revoked membership rejects preparation. The action accepts an optional exact archived revision and explicit baseline job ID; it returns private artifact metadata rather than source bodies.
src/p4-shelf.ts provides one shared ingestion implementation for this action and openreview p4 review. It overlays native archived additions/edits/deletions, compares the complete diff's left-side context with the indexed submitted baseline, preserves unchanged caller context, and records native versions/archive changes/base file revisions. Excluded changed sources are removed from baseline context. Persisted changed source and diff text are redacted. Project/view/state/revision changes, unmatched or unavailable baselines, unexpected source identities and context over 20 MB fail visibly. Baseline manifests predating retention must be regenerated by uploading a fresh index.
This internal preparation step makes the hosted baseline/shelf input available to durable review dispatch. It does not itself run inference, publish comments, expose a user-facing review trigger, enable automatic polling, launch an agent or approve a change. The dispatchers below supply inference/publication and opt-in review polling; agent launching, approval and native external acceptance remain outstanding.
Manual hosted archived-shelf review
After the submitted project index finishes, open Settings → Code providers → Inspect native reviews and choose Review archived shelf for an open pending review. The bot needs native comment permissions in Code Review in addition to read access to the archived shelf. A workspace admin can also send POST /api/p4/reviews with an OpenReview API key and JSON { "repositoryId": "<OpenReview repository ID>", "nativeNumber": 12 }; the bounded request returns HTTP 202 and reviewId. Optional force: true creates a new review at the current shelf revision. Ordinary duplicate requests reuse the existing current run. No source content or ticket is accepted from that request.
Preparation pins the archived native shelf to the completed baseline. A durable worker applies effective review settings, custom rules, learned preferences, existing finding assessment and referenced issue requirements through the shared review engine. It saves findings, diagnostic coverage, structured summary and model calls before publication. Review revisions remain native opaque IDs, not invented Git SHAs. Native right-side publication maps depot-relative engine paths back to //depot/... and uses the pinned base-file revisions. Results appear in Pull Requests with history and processing stages; Re-review current PR dispatches a fresh native request. View/Re-review and Fix links are published. Fix requires the latest completed review with eligible unresolved findings and a matching registered native client.
The worker claims a 15-minute lease, checks it and current requesting-admin/connection/baseline identity during work, and rejects completion from a replaced or expired worker. Recovery waits for live leases. Native publication rechecks authorization and integration scope before each operation. Changed or closed shelves cancel obsolete reviews; revoked access prevents inference/publication and stops after bounded retries. Persisted results allow a publication retry without repeating analysis. This workflow does not enable automatic polling, cross-repository retrieval, P4 agent fixes, runtime checks or automatic approval. Contracts with a stub model and native publisher prove dispatch wiring and guards, not a live installation, model accuracy or native publication acceptance.
Durable native review polling
After indexing completes, a workspace administrator can Enable review polling in Settings → Code providers. This is separate from generic Git indexing/enable controls and starts disabled. Restart / retry polling selects the current completed submitted baseline and records a new authorization generation. Disable polling cancels that generation’s queued automatic reviews and pending polling steps, while preserving separately requested manual reviews. No credential is accepted by these controls; the existing encrypted native connection and current admin identity authorize the job.
A durable cursor walks every visible review page in creation order, including older reviews whose archived shelf changes later. One step fetches a page or processes one native review; subsequent steps wait four seconds, and a complete inventory restarts after five minutes. Large inventories take correspondingly longer to finish. Each page/row checkpoint and scheduler identity is persisted. A worker uses an expiring lease; recovery reuses live jobs, replaces expired work, and rejects stale worker mutations. Native private-project/server protections may hide reviews or files, so the UI does not claim complete server-wide coverage. Native API review ordering and pagination define the cursor; updated-day ordering is not used because it can ignore the native page-size bound.
Polling checks native current project branches and review state before dispatch. The shared Automatic review and Re-review settings apply. Target/ignored branch globs match the native branch IDs associated with the selected project; this provider has no Git head/base branch pair. New opaque revisions enqueue the existing archived-shelf worker. The same already queued/completed/failed revision and baseline are not repeatedly analyzed; a failed run remains available for explicit manual retry. Closed/submitted/archived reviews cancel unfinished work. Shelves without an archived pending changelist are recorded as skipped without inference, with recent reasons visible in the portal.
Current admin membership, repository access, original connection/credential digest, completed baseline and polling generation are rechecked at queue/save/publication boundaries. Automatic settings changes also prevent subsequent automatic analysis/publication. Re-indexing, replaced credentials or revoked admin access require an explicit administrator restart using the new trusted baseline. Errors persist with at most three polling attempts before visible failure; a failed poll is not restarted by recovery. The inventory ceiling is 100 nonempty pages / 10,000 visible reviews; a terminal empty page is permitted to prove completion at the ceiling. Exceeding it fails visibly. Recovery currently inspects at most 1,000 enabled native projects.
Portal status includes current page/cursor/row, cumulative scanned/skipped counts, recent skipped reasons, next step, last completed inventory and failure attempts. The last completion time is only written after the entire inventory finishes; it does not hide an unfinished or failed scan. This feature does not poll submitted-depot inventories, run P4 agent fixes/runtime checks, approve or merge changes. Contract tests cover older-shelf revision detection, duplicate suppression, leases/recovery, policy/generation revocation, branch filters, missing archives and pagination/coverage failures. External acceptance still requires a reachable P4 installation and disposable native review.
Native installation acceptance (2026-10-03)
A disposable official P4 Server 2026.1 and digest-pinned P4 Code Review 2026.1 run in Docker, with SSL server identity, dedicated users, scoped read-only bot depot protections, authenticated Redis, and a private native project. The official macOS ARM64 P4 CLI was verified against the vendor SHA256 before use. This fixture contains only synthetic acceptance source; its temporary HTTPS proxy depends on the local machine and is not production hosting.
Native acceptance has verified project discovery, private-project bot membership, archived shelf identity, digest-checked source and complete diffs, and the four-file submitted baseline through both the real CLI indexer and hosted durable index jobs. The correct baseline passes its local regression; the defective shelf fails. These separate fixture checks are not hosted runtime evidence.
Live responses exposed compatibility errors missed by mocks: -Mj stat records omit code, the server identifier is ServerID, native print rejects the attempted conversion options, current file metadata uses fileName, content links omit the requested revision, and legacy comment pages omit the top-level topic and may return nonempty arrays instead of keyed records. The shared adapters now handle these shapes, pin downloads with v, and reject diagnostic records or mismatched metadata/digests. Project branch views are fetched from the individual project API when inspecting native reviews; the catalog can return an empty branch list even when views exist.
Publication uses the current v11 JSON comment endpoint with version, file, both line sides, text type and up to five lines from verified archived source. The legacy v9 inline write path attempted to read protected native keys as the bot. No admin depot grant or reduction of dm.keys.hide=2 is required by the v11 path. Per-comment publisher/topic/version/file/line/excerpt identity remains checked, and the summary is published last. A failed saved publication can be retried by a workspace administrator without repeating model calls. The retry rejects superseded runs, replaced credentials/baselines, unfinished indexing, revoked access and obsolete polling generations; the worker still rejects changed or closed native shelves.
Native publication, polling and updated-shelf results are recorded separately in docs/implementation-status.md; do not infer acceptance of follow-ups, P4 Fix, runtime, approval, automatic depot indexing or cross-repository retrieval from indexing or model findings.
The subsequent hosted polling acceptance completed native review 10 without manual comment writes: automatic inventory discovery → shared model review → inline comment 3 → summary comment 4. Native readback confirmed archive 11/version 1 and billing.ts right line 4. Eight model calls cost $0.043130; polling was disabled after the fixture test. Evidence lives in output/setup/p4-native/poll-publication-evidence.json. Updated-shelf and P4 Fix/runtime/approval acceptance remain outstanding.
Updated-shelf acceptance also passed: reshelving the corrected fixture automatically archived version 2/change 12; polling discovered the changed revision and the shared resolution assessment recorded the earlier critical defect resolved while preserving version 1 history. Native summary 5 was published after a saved-result retry fixed filtered empty-page pagination. Strictly advancing cursors can traverse empty version-filtered pages; stalled cursors and bounded coverage still fail. Evidence: output/setup/p4-native/updated-publication-evidence.json. The fixture author made the edit; this does not establish native agent Fix acceptance.
Register a native local checkout
The bridge can register an existing P4 client using its installed official CLI, existing ticket and SSL trust:
openreview bridge register-p4 /path/to/client \
--server ssl:p4.example.com:1666 --client YOUR_CLIENT \
--instance https://review.example.com --project PROJECT_ID
Registration records the native server ID, client, owner and canonical root; it does not store a P4 password/ticket, sync files, create a changelist or launch an agent. The client must use noallwrite and Unix line endings so server digests can be compared directly with local bytes, including on Windows. Register the actual HTTPS Code Review origin and project ID. Existing Git registrations remain compatible.
The native verification helper checks server/user/client/root identity, have revisions, mapped paths and pinned file sizes/digests before allowing a checkout to be used. Symlink escapes, different source bytes, stale native identity, missing mappings and excessive manifests fail without changing files. Unrelated existing changes are preserved. Source verification repeats native identity after reading files.
The real macOS acceptance fixture registered openreview-host-fix and verified four files against submitted baseline 5 and review 10 archive 12. Wrong server identity was rejected. Evidence: output/setup/p4-native/bridge-verification-evidence.json. Native P4 server dispatch now returns a bounded, credential-free manifest after rechecking the current archived shelf, baseline and access. Registration verification alone is not proof that a P4 agent launched.
Native Fix scope
Fix and Fix All use the paired bridge and personal agent choice. A click creates a five-minute single-use request. The claim checks current membership, latest completed review, original indexed baseline/credential authority, live native shelf and unchanged project views. The local bridge validates the native server/client plus every indexed context file and changed shelf file before running the selected fixed agent adapter. It does not infer resolution from launch or successful exit.
The native adapter verifies existing edited readable sources, new added sources and deleted baseline sources, up to 1,000 manifest files and 20 MB. Changed sources must match their exact archived native action. Additions require no submitted have revision; deletions retain the indexed baseline digest and require the local target to be absent, including when its empty parent directory is removed. Branch/move action variants are validated by the same manifest rules but lack live acceptance. Re-adds over an older deleted baseline path, skipped/unreadable changed files, translated line endings or different have revisions are rejected before launch. The native client must already be prepared at the reviewed shelf over the submitted baseline; OpenReview does not sync, unshelve or overwrite it. Existing local P4 authentication and SSL trust are required. Agent prompts forbid submit, sync, unshelve, mapping changes and reverting unrelated files; necessary native action changes are restricted to reviewed target files. They require an inspectable native diff with actual regression results.
Contract tests cover native task issuance, replay, stale/closed shelves, revoked access, launcher success and stale checkout rejection. Live claim and native launch acceptance are recorded separately; contracts do not establish native agent execution on all supported operating systems.
For desktop launches, registration can pin local tooling and authentication files without relying on shell environment variables:
openreview bridge register-p4 /path/to/client \
--server ssl:p4.example.com:1666 --client YOUR_CLIENT --user YOUR_USER \
--instance https://review.example.com --project PROJECT_ID \
--p4 /absolute/path/to/p4 \
--tickets /absolute/path/to/tickets --trust /absolute/path/to/trust
Use existing native login/ticket and verified SSL trust files. These are local path references; their credential contents are not stored in bridge configuration or sent to OpenReview. Explicit ticket selection removes an inherited P4PASSWD override. Server/client/user settings are passed to the selected agent; its prompt identifies the configured P4 executable for native diffs. Repository-local P4CONFIG is disabled for these reads. Registration validates regular canonical local files; native identity and source verification still run before every dispatch.
The macOS acceptance now includes a real hosted Fix click that passed native verification and launched the actual Codex process for review 7/archive 8. Request replay was rejected and the finding remained open. Evidence: output/setup/p4-native/desktop-launch-evidence.json and desktop-agent-process-evidence.json. Agent completion, regression results, author reshelving and subsequent resolution acceptance are still pending; computer-use control of Terminal was denied, so the native agent session requires human completion.
Added/deleted read-only acceptance used a separate native client at baseline 5 and review 14/archive 15. The real CLI verified five manifest entries, including a new source with no have revision and a deleted source whose parent directory had disappeared. No agent or model ran for this fixture. Evidence: output/setup/p4-native/actions-verification-evidence.json. Agent execution for these change types and live branch/move acceptance remain pending.
Native follow-up reply transport
The read adapter preserves native context.comment parent identities and can publish a version-pinned threaded reply using the v11 comment endpoint. It checks the current archived shelf and native question body/author/context before publishing, rejects archived or changed questions and closed shelves, and validates native publisher/topic/version/parent/body readback. A saved answer retry reuses only a matching bot reply with the exact marker, parent and body; conflicting or archived replies fail. A caller may revalidate workspace authority before each publication boundary.
The real native transport fixture created author question 6 and bot reply 7 on review 14/version 1; native readback confirmed the parent and exact publisher and replay created no duplicate. The answer was scripted from fetched archived source, with no model or runtime execution. Evidence: output/setup/p4-native/reply-transport-evidence.json. This transport result alone is not full native follow-up acceptance; see durable answers below.
Personal native identity and follow-up evidence
Personal agents settings now offers a repository-specific native P4 identity link for workspace/team writers. Link an existing username and P4 login ticket; OpenReview checks the effective authenticated native user through GET /api/v9/session and reads the selected project as that user. The encrypted credential is bound to the workspace, repository and OpenReview account. The link expires after 24 hours; a native ticket can expire earlier. Disconnect removes the stored credential and increments its generation. Public listings never return the credential. Bot credential replacement, provider suspension/disconnection, lost writer membership, identity replacement and expiration stop subsequent reads.
The internal follow-up evidence action requires the latest completed native review and its original indexed baseline. It locates the current question as its linked native author, verifies their accessible snapshot/project scope, and retrieves both changed archived files and unchanged submitted callers using that author's ticket. Forbidden or missing sources are omitted with coverage reasons; authentication failures stop retrieval. The reply context is bounded to 20 files/40,000 characters and rechecks identity, question context and open shelf revision after reads. It supplies no execution evidence. This prevents using bot-only source access to answer another native user.
Native authentication reference: P4 Code Review login/session API.
Durable native answers
Enabled native polling discovers current-version questions mentioning @openreview on the latest completed native review. Each author must have a valid linked personal identity and current workspace/team writer access. Discovery runs even when automatic new reviews are disabled. It does not answer an unreviewed or superseded shelf.
Questions are deduplicated by repository and native comment ID. Workers use expiring leases with at most three attempts and durable scheduled recovery. Model answers use only personally fetched sources, exact validated quotes and pinned source links; test assertions are described without claiming execution. Usage is recorded separately from the original review. Saved answers are reused after publication failure; cited sources must remain available to the author at every native publication boundary. Question edits, revision changes, identity revocation/expiry, lost membership, provider changes and stopped/replaced polling fail closed. Native reply markers allow replay to reuse an exact bot-owned threaded answer.
Review details show native question status, attempts, errors, saved versus published answers and native reply IDs. Only the linked author can retry a failed answer after restoring identity/polling authority. Retry rebinds current credential and polling generations while retaining the original revision; a new revision requires a new question.
Live hosted acceptance discovered existing author question 8 on review 10/version 2 and published threaded bot reply 9 on its first attempt. The answer cited personally fetched price.ts and billing.ts at pinned revisions. Native API readback confirmed author, parent, version, marker and exact answer; completed-worker replay caused no model call or duplicate publication. One answer usage record cost $0.003596; original review model calls remained eight. No runtime execution or manual answer write occurred. Polling was stopped and the original review settings restored after acceptance. Evidence: output/setup/p4-native/conversation-live-evidence.json. Computer use verified the published answer/status in OpenReview (conversation-portal.png); the native modern discussion view displayed older-version comments despite its updated count, so latest-version native browser display acceptance remains open. Broader commands, provider/OS/runtime/mobile acceptance and full parity remain unproven.
Explicit native commands
The entire comment must be @openreview ignore this pattern, @openreview re-review, @openreview rereview or @openreview review again (case-insensitive; a final period or exclamation mark is permitted). Quoted code, incidental mentions and combined commands do not execute a command. Command acknowledgements are deterministic and consume no model inference.
Pattern suppression must reply to a currently published, open finding at the reviewed revision. The author must be able to read its native bot-owned parent, including the exact finding marker; this is rechecked at publication boundaries. A single inspectable repository preference and saved acknowledgement are written atomically, with the author request and source finding/review recorded. It leaves the existing finding open. Admins can disable the preference while retaining its history.
Re-review requires workspace admin access and preparation of the exact current archived shelf against the original submitted baseline. A conditional native acknowledgement is published first; completion then atomically records the reply receipt and queues one forced review with its linked request ID. A lost reply response reuses the same acknowledgement, and completed command replay cannot queue another review. Review details link the requested re-review. Contracts verify its preparation, receipt, queue, replay and non-admin rejection.
Live pattern-command acceptance discovered author question 10 under finding comment 1 on native review 7/version 1. It saved one preference and published bot reply 11 on its first attempt. API readback and replay verified the native parent/version/body, one preference, zero inference and an unchanged open finding. Computer use inspected the preference's provenance and disabled it through Memory's actual control. Polling and original settings were restored afterward. Evidence: output/setup/p4-native/command-live-evidence.json, command-portal.png and command-preference-disabled.png. The underlying original inline finding had the previously recorded diagnostic-publication caveat; this acceptance establishes the command flow, not a new inline-publication result.
Live re-review-command acceptance discovered author question 12 on native review 10/version 2, published threaded acknowledgement 13 and automatically queued one new OpenReview review at that exact archived revision. The hosted review completed with seven model calls costing $0.016864 and published native summary 14. Native readback verified both publication markers, publisher, revision, version, parent and saved body; completed-command replay created no review, publication or inference. Computer use followed the actual requested-review link and verified its completed result and history. No runtime execution, manual review launch, automatic approval or merge occurred. Polling and original settings were restored. Evidence: output/setup/p4-native/rereview-live-evidence.json, rereview-command-portal.png and rereview-result-portal.png. These results do not establish wider provider, OS, runtime or full parity acceptance.
Exact shelf runtime validation
Opt-in runtime validation uses a separate raw archive, not indexed or redacted review context. It overlays the pinned archived shelf on every enumerated regular file of the selected submitted baseline, retrieves native revision-pinned bytes, verifies size/digest, includes binaries and executable modes, and applies additions/deletions. Depot-relative paths are retained; approve a command such as cd depot/main && node --experimental-strip-types --test tests/billing.test.ts. Native opaque shelf identity is preserved in worker claims and execution evidence.
The archive is bounded to 20 MB uncompressed, 10,000 files and USTAR paths. Unsupported actions/types, missing metadata, inaccessible sources, project-view changes and shelf changes fail visibly. It does not reproduce a native client mapping or measure files hidden by P4 protections. The original operator-enumerated baseline and its limitations remain explicit. Runtime authority checks the baseline, credential identity, original requester access and any automatic polling generation; source access and evidence attachment stop after revocation. Reviews release their native lease while waiting and acquire a new lease after the durable runtime result arrives.
Real Docker execution of native review 7/archive 8 failed its currency regression (5.97 versus 597); native review 10/version 2/archive 12 passed the same one-test command. The hosted durable flow for review mx72f9jenms6brnpq13vxdf80x8fk5g8 prepared the native archive, claimed job qh77g31qpmrpz59480snthqq898fjts0, executed it with a digest-pinned Node image/no network, recorded exit 0 at the exact shelf identity and resumed the real model review. Native summary comment 15 was read back with the exact saved summary at version 2. Seven model calls cost $0.026702; total hosted inference is $1.751818. Completed request replay caused no new inference. Evidence is retained in ignored output/setup/p4-native/runtime-native-evidence.json and runtime-durable-evidence.json. This establishes temporary local-worker execution, not continuous worker hosting, P4 automatic approval, native Fix completion or broad parity.
Authorized mixed repository context
Linked native review authors can retrieve explicitly selected cluster sources through the shared reader. A Perforce source additionally requires that author's personal identity on the source repository, a ready submitted baseline and fresh native authentication/file access. Bot credentials never substitute for the author ticket. Sources retain native file revisions, submitted inventory identity, repository provenance and revision-pinned links. The reader selects up to ten indexed files per repository and 100 KB total; native inventory limits remain explicit.
Review/cache/publication receipts bind the author, exact cluster membership, source access, provider credentials, indexed revisions and personal identity generation. Review, finding and Fix readers require access to all recorded participating repositories. Changed or missing prior cross-repository evidence is withheld from a subsequent review and remains unresolved. Saved publication retry fails after authority changes; a fresh current-shelf re-review is available. See shared context details. GitLab and Gitea primary reviews now support verified connection-specific personal author links; other primary native providers still require their author adapters. Username equality cannot authorize retrieval.
Live mixed-context acceptance fetched submitted P4 sources with the author ticket in one direction and pinned GitHub sources in the other. Native review mx71fehpkjw6dapavqst319r9h8fkv9b published summary 16 with five actual Git source paths, their indexed revision and a truthful unexecuted-test status. Native readback and the hosted portal matched; the temporary cluster was removed. This verifies retrieval and publication on these fixtures, not broad provider or native permission acceptance. Evidence: ignored context-retrieval-evidence.json, context-publication-evidence.json and context-portal.png. Hosted inference total is $1.785864.
Read-only native approval inspection
Settings → Code Providers → select a P4 project → Inspect native reviews → Inspect approval blockers reads the exact archived shelf inventory and the native v11 transitions endpoint. The result shows native review/version, opaque revision, timestamp, current state, whether the bot is offered an approved transition, and generic moderator/vote/test restrictions. Native blocker names, users and private project metadata are never returned to the portal. Snapshot reads before and after retrieval reject observed revision, state or update changes. This is a point-in-time diagnostic, not an atomic approval authorization.
The action requires workspace administrator access before and after native retrieval and rechecks that the active connection, instance and encrypted credentials are unchanged. Suspension, disconnect, credential replacement or membership revocation fail closed. It performs only GETs. No votes, review transitions, commits or submits are issued.
Automatic approval remains unavailable for Perforce. The documented state-transition request has no revision parameter; the version guard belongs to voting. A version-bound vote does not establish a version-bound native approval transition. Even when the native bot is offered an approval transition, permission-filtered inventories cannot prove that all affected files were reviewed. A future writer must retain this coverage gate, version-check votes, prove bot-owned receipts before withdrawal, respect native checks and human objections, and never invoke approved:commit or commit transitions. The native v11 vote API rejects explicitly stale versions; omitting its version targets the latest review and is unacceptable for an automated writer. See the official native review API.
Native continuous watcher acceptance (October 4, 2026 UTC)
A temporary live openreview p4 watch process observed baseline 17, then detected new submitted change 21 without restart or manual upload. It queued a three-file manifest with one changed source; the hosted index completed and already enabled polling adopted the baseline. Native review 23 was reviewed and published with one cross-file billing finding, source-linked inline comment 19 and summary 20. All fixture tests remained source evidence; no runtime execution is claimed. The process was stopped, automation disabled, temporary key revoked and prior CLI configuration restored. A persistent supervisor remains an operator deployment prerequisite. See acceptance evidence.
October 4 approval-capability hardening: the repository policy API rejects enabling Perforce automatic approval, while allowing disabled legacy overrides to be retained or removed via Sync from parent. Organization/team policies may remain enabled for supported providers. If inherited approval dispatch reaches a P4 review, the durable job becomes unsupported without provider reads or writes; subsequent change rechecks retain that status rather than repeatedly failing in the Git adapter factory. An unexpected existing approval receipt retains withdrawal intent instead of being hidden as unsupported.
Durable regression proves capability filtering, direct policy rejection, inherited dispatch/recheck with zero native calls, disabled-override cleanup and receipt retention. Full checks: 170 Node + 137 Convex = 307 tests, lint, typecheck and build. Backend deployed to tidy-ocelot-457; no frontend/schema/environment change. Live policy rejection is confirmed by its correlated native production function log with zero database writes; the actual repository remains excluded from approval settings. No approval, policy change, model call or new job was requested successfully. Evidence: output/setup/p4-approval-capability-live-evidence.json and p4-approval-capability-{regression,typecheck,lint,build,convex-dry-run,convex-deploy}.log. This does not claim native P4 approval support.