From your first review to an approved fix.

1. Sign in to your workspace with GitHub.
2. Install CodLab AI and select the repositories it can access. Your own GitHub account must also have access.
3. Use the setup panel to select an authorized repository. Refresh GitHub access after changing installation selection.
4. Open or update a pull request. Inspect the latest review status for that repository.
5. Open the completed report, check its exact SHA, coverage and evidence, then record useful finding decisions.

Supported rules inspect actual JS/TS operations. AI analysis reports its file and hunk coverage. Disabled, omitted, unavailable or partial analysis does not prove a clean change. Malformed AI responses cannot become a completed empty result.

Repository impact is a bounded static JS/TS sample, including observed imports, calls, aliases, re-exports and relevant tests. Select a file in the impact view to inspect source relationships. It does not establish production deployment reach or a verified exploit.

Configuration resolution evidence

In the review-evidence update, the existing impact view includes a commit-bound configuration receipt. Supported local JSONC and TypeScript inheritance preserve relative option origins. Project references identify inspected configuration relationships; they do not merge compiler paths or establish that declarations were built. Conditional package exports stay unknown when inspected branches disagree. Missing, conflicting or over-budget metadata is reported explicitly.

Static context remains bounded to 24 files and 384 KiB of source, including its metadata reads. A displayed relationship does not establish full repository coverage, deployed reachability or successful tests. Availability depends on the deployment version; earlier reviews cannot gain evidence that was never collected.

Security details separate observed evidence, inferred prerequisites, counterevidence and proposed hardening. Evidence coverage scores are not merge-safety guarantees. Empty or unavailable CI earns no CI coverage credit.

Local candidate · 2026-10-06.1-financial-security. This section describes the unpublished update. The saved operator flag FINANCIAL_SECURITY_ENABLED remains false. Configuration and owner staging acceptance must precede activation; these notes do not establish live availability.

Choose a separate repository profile

• Banking & Payments (banking-payments) adds bounded checks for supported Stripe monetary conversions and constant idempotency keys, plus native cryptography and HTTPS diagnostics. It does not verify ledger balances, transaction authorization, database atomicity, reconciliation or durable application idempotency.
• Crypto Wallets (crypto-wallet) records supported ethers/viem signing, verification, transaction and receipt operations. An explicit typed-data domain outside the declared EVM chain scope receives an advisory. Custodial, noncustodial and smart-contract wallets are separate declarations; custody, replay consumption, finality, reorg recovery, oracle/bridge behavior and contract correctness remain unverified.
• General review remains the default. Public uninstalled PR reviews stay general. A profile declaration does not expand GitHub access or turn on customer code execution.

Current native capabilities and limits

The pack inspects parseable JavaScript/TypeScript patch fragments without executing repository source or tests. Supported native Node imports can identify static AEAD IV inputs, predictable Math.random contributions to key/IV inputs and explicit rejectUnauthorized: false options on HTTPS requests or agents. API aliases, shadows and visible mutations are treated conservatively. Source operations and policy mismatches are advisory, not verified exploits or financial loss.

The low-severity fixed Permit nonce advisory recognizes an immutable fixed nonce in an exact ERC-2612-style Permit signing input through supported ethers/viem APIs. A fixed current nonce, including 0, can be valid for one authorization. Compliant contracts check and consume nonces(owner), so this advisory does not establish replay acceptance or a defective contract. Dynamic nonces, custom schemas, visible mutations and possible freshness guards remain unknown. Inspect the intended token, owner, chain and nonce freshness.

Node, depth, operation and elapsed-time budgets can stop inspection earlier. Unsupported, unparsed, ambiguous or over-budget scope stays unavailable or partial. Solidity, Rust and other languages are not supported by this native pack. No findings never means these controls passed.

Financial evidence binds the exact reviewed SHA, pinned ruleset, workspace policy version and canonical declaration digest. Inspect per-file coverage, observed source operations and unassessed controls in the report. The inventory omits key, seed, IV, certificate and transaction values. It is not a complete CBOM/SBOM or proof of key lifecycle, cryptographic module validation, certification or calibrated detection accuracy. This pack does not run external SAST, dependency, secret or infrastructure scanners.

Explore settlement and reorganization observations

The financial security candidate's lab contains 16 synthetic settlement and reorganization presets. It models invented pending, reverted, included, safe, finalized and orphaned receipt observations, plus removed logs. The same bounded offline evaluator powers the lab and its regression fixtures. No wallet connection, RPC request, customer source or test execution, or funds transfer occurs. These caller-supplied provider observations do not establish real-chain finality, consensus, ancestry, actual settlement or customer security controls.

Current administrators configure the declaration

1. Open Review policies and select the Financial security panel and authorized repository. Only a current repository owner/admin with valid GitHub and installation grants can read or change this setting.
2. Select the mode and inspect its explicit declaration. The repository API is /api/repositories/{id}/financial-security; authenticated GET reads current state and versioned PATCH changes it. Writes reject stale versions and create an atomic audit record. A transfer clears the old declaration and author, moves a general-policy tombstone to the receiving installation and advances the existing version. Its administrator must explicitly declare a new profile; transferring away and back cannot revive old approvals or signed validation.
3. The JSON body is limited to 8 KiB and accepts exactly version, mode and manifest. A financial manifest accepts exactly currencies, wallet_kind, chains and protected_paths. Use public or synthetic metadata only.
4. Declare up to 20 unique uppercase three-letter currency codes with minor-unit precision from 0 to 8. Banking mode requires a currency, wallet_kind: null and no chains. Wallet mode requires custodial, noncustodial or smart-contract; up to 10 unique positive safe-integer EVM chain IDs can declare safe or finalized policy. An empty chain declaration produces no chain-scope diagnostic. General mode uses manifest: null.
5. Up to 30 safe relative protected_paths entries describe intended scope. They do not grant access or create an enforcement allowlist. Every financial-mode fix receives the stronger approval rule, including paths outside this metadata.

Neither a PR's .codecr.yml, a comment nor model output can select or weaken this trusted mode. A declaration states intended policy; it does not prove that an application enforces it.

Financial fixes require two people and signed validation

Both a new draft pull request and publication to the current PR branch require two distinct current authorized administrators and passing signed isolated candidate validation. A new PR is the default. The approval binds the patch hash, reviewed head, destination and financial policy seal. Changed policy, patch, head or destination invalidates stale approval; revoked grants, missing validation and unavailable gates fail closed, including before GitHub mutations.

Customer execution remains disabled until the isolated runner is independently qualified. A configured runner URL, a proposed test plan or unrelated passing CI cannot substitute for the required signed candidate evidence. Inspect resulting exact-commit CI before any merge. No automatic merge is authorized.

Owner release preparation

On an existing database, migration 0017 advances every current financial-policy version once while retaining its mode, declaration, author and historical evidence. Pre-upgrade financial seals are invalidated. Reload policy forms and obtain a fresh review, proposal, two-person approval and signed validation before publishing a financial fix. Empty fresh databases have no existing policies to advance.

The owner reconciles the actually deployed foundation migrations 0011–0015, then inspects and applies only pending additive 0016_financial_security.sql, followed by 0017_financial_policy_epoch.sql. Keep 0016 byte-identical. The candidate expects schema codecr-runtime-v17; the queue stays codecr-review-job-v1. Do not reset production data or run a fresh-install bootstrap on an existing database. Keep analysis and execution/fix gates disabled until separate staging and runner acceptance, using synthetic fixtures without real funds, account data, keys or seeds.

Read the candidate's financial security scope · Review the general patch workflow

1. Generate a patch for findings, docstrings, tests or readable failing CI evidence. Cancel while it is queued or generating.
2. Inspect the diff and its limitations. Documentation goals reject executable JS/TS behavior changes.
3. Select a draft pull request or the current PR branch. Protected and default branches retain their publication safeguards.
4. Approve the exact hash, reviewed commit and destination. An organization can require two distinct administrators with current repository grants.
5. Inspect exact published-commit CI evidence. Pending checks are re-observed for a bounded period; source cleanup preserves a small publication manifest for later refresh.

Isolated execution availability

Isolated execution is unavailable in the current hosted release. CodLab does not run your project’s tests before publication. The proposed plan and signed-receipt protocol require a verified isolated runner; unavailable infrastructure and missing tests cannot pass. Inspect GitHub CI before merging.

Uncertain publication

If CodLab cannot confirm its publication receipt, GitHub may already contain the fix. Inspect GitHub before starting another proposal.

Review policies, repository guidance and retention · Audit history · Members · Recorded security scans. Sign-in and current workspace/repository grants are checked at the destination. These links do not grant permission.

Owners and administrators manage versioned review policies, scoped audit search and paginated export. Policy previews show the last observed trusted repository configuration and its immutable base, alongside clearly separate illustrative scenarios. Unobserved repositories remain unknown.

AI supporting context is off by default. Current repository owners/admins can opt in to bounded adjacent helper, guard and test excerpts only with an enabled operator gate. Static context and AI packet coverage are separate; omissions remain visible and no whole-repository or zero-retention promise is made.

Under Trusted CI, repository owners/admins can explicitly configure expected check/status names and verified producer IDs. Same-name results from other producers do not satisfy this policy. This expected set is separate from GitHub branch rules, merge-queue coverage and proof of actual test execution. With no readable approved set, expected-set satisfaction stays unknown.

Reviewers can suggest repository guidance after recording a finding decision. Administrators explicitly activate, archive or restore revisions. Guidance is repository-scoped, expires, and never weakens deterministic security controls.

Evidence retention is manual and preview-bound. Report snapshots, eligible finalized recovery payloads and terminal source payloads can be deleted after an exact preview; identifiers, findings, feedback, validation and audit records remain. The inventory distinguishes application evidence from provider-managed logs and unreported backup state.

Worked synthetic workflow

1. Open a completed report from the review queue. Confirm its SHA and cited line; record accepted, false positive, reviewer-assessed fixed or accepted risk. A decision is not test evidence.
2. After saving a decision, propose a specific repository instruction. It remains inactive. An owner/admin inspects and activates the revision under Review policies; expiry still applies.
3. For retention, select the authorized workspace and inspect inventory. Save the period, preview eligible evidence, inspect the exact count, then explicitly apply that preview. A changed preview or role requires a fresh preview.

Explore the synthetic report and approval walkthrough. It uses production report components with invented inputs; no repository, CI or payment action occurs.

GitLab, Bitbucket and Azure sign-in do not establish repository-review support. Enterprise identity connections and deployment contracts require their separately documented verification lifecycle.

The setup panel restores your selected repository within your browser session and checks it against current grants. Refresh status while a review is queued, processing or retrying. A failed review should be opened for its recorded error before re-running.

Repository grants expire independently of installation membership. Reconnect GitHub to renew access; restore suspended installations in GitHub. A revoked approver cannot publish, and a retry cannot silently substitute another publishing actor.

Inspect Billing for actual subscription state, used and reserved reviews, and the current quota. A payment or cancellation remains an explicit account action.

GitHub rate-limit responses retain a retry time and resume through bounded recovery. A permission failure is separate. Completed publication clears its recovery report payload while retaining provider identifiers; incomplete publication retains the payload for reconciliation.

Delivery timeline

The review-evidence update adds Refresh delivery status to saved review details. New runs record bounded stage and attempt milestones; older runs show that historical milestones were not recorded. The retry timestamp is the earliest recorded eligibility, not a start reservation or completion estimate. Publication status describes the local journal and does not independently verify GitHub. A refresh only reads current authorized data; it does not resend or rerun work.

Milestone history is limited to the latest 100 observations. Earlier or explicitly deleted metadata remains unavailable. Eligible terminal milestones appear separately in the administrator retention preview, consent and audit receipt. Missing evidence must remain unknown.

State and recovery guide

Support · Security and processing boundaries · Privacy · Website terms and service information