[GH-ISSUE #4396] [Feature] Require a failing negative control before a reconstruction verifier closes an obligation #1748

New issue

Open

opened 2026-10-16 21:09:48 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented 2026-10-16 21:09:48 +00:00

Owner

Copy link

Originally created by @coygeek on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4396

Before submitting

• I searched the open and closed issues and pull requests for a related proposal.
• I understand the contribution scope must be reviewed before integration; open questions are welcome here.
• This request does not include credentials, private samples, or sensitive target data.

Area

Evidence, artifacts, or reconstruction

Current limitation

build_reconstruction_obligation_ledger closes an obligation when a manifest binding supplies a unique owner, required fixtures, and "a passing verifier whose authority is comparable to the original observation. The verifier must enumerate the obligation ID and its result must be present in the input Evidence bundle." (docs/reconstruction-obligation-ledgers.md). The verifier binding carries command, authority, status: "pass", result_evidence_id, and enumerated_obligation_ids.

Nothing in that binding shows the verifier can distinguish a correct reconstruction from a wrong one. A verifier that always passes, for example one that enumerates the obligation ID but asserts nothing, or one whose comparison silently skips the relevant dimension, meets the stated closure rule. The negative value of obligationCaseKindSchema (src/domain/reconstructionObligationLedgerSchemas.ts) describes negative inputs to the target's behavior ("reject an invalid configuration option"), not a negative control on the verifier itself. verify_reconstruction takes only a specification and checks claim authority; evaluate_reconstruction_coverage checks evidence provenance.

REA already applies this discipline internally: npm run verify:readiness fails closed if "a deliberate primary divergence is not localized" and keeps "every deliberate fault" represented (docs/reconstruction-readiness.md). That protects REA's own comparators, not the verifiers a user binds into a ledger.

Use cases

• An agent reconstructs a protocol handler and writes a conformance test as the verifier. Before the ledger closes the obligation, it should show the same test failing against a build with one deliberate defect (wrong field order, dropped error path).
• Reviewing someone else's reconstruction claim: the ledger shows which closures rest on verifiers that were demonstrated to fail on a known-wrong input and which were never challenged.

Open false-green and false-red reports in the reconstruction area (#3937, #3984; closed #3980) show that closure logic is already a source of incorrect results; this request addresses the verifier side, which those issues do not cover.

Desired outcome and success criteria

Let a reconstruction obligation ledger record a negative control for each verifier binding (a deliberately wrong candidate and the verifier's observed failing result), and keep closure open or unknown when no control shows that the verifier can fail.

• A verifier binding can include one or more controls, each naming the deliberately wrong candidate (by artifact identity or fixture), the defect it introduces, and the Evidence ID of the verifier's observed failing result.
• The ledger reports, per obligation, whether its verifier has a passing result on the candidate and a failing result on at least one control; a control that also passes is reported as a vacuous verifier, not ignored.
• Closure policy is explicit: an obligation without a demonstrated failing control does not report the same closed status as one with it (either it stays open or it closes with a named limitation; maintainers choose which).
• Existing ledgers without controls still parse; their closures are labeled as unchallenged rather than silently upgraded or rejected.
• Documentation explains how to construct a one-defect control and why a control that passes is evidence against the verifier.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

The ledger reads Evidence and manifests only; running the verifier and the control stays with the caller, as it does today for the passing result. Non-goals: REA generating mutants automatically, or running caller verifier commands.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

Possible fixture: a ledger with two obligations bound to the same trivially passing verifier, one with a control whose result also passes and one with a control that fails. Expected: the first is reported as a vacuous verifier and not closed; the second closes.

Alternatives considered

• Relying on reviewers to notice weak verifiers: does not scale and is not recorded in Evidence.
• Expressing controls as additional negative cases: conflates target behavior with verifier sensitivity and would let a verifier that ignores its input satisfy both.

Possible direction

Model a control as an optional array on the verifier binding with its own result_evidence_id and expected status: "fail", and surface the per-obligation result in the ledger output next to existing closure reasons.

References

• Checked against main at commit 8ab5024 (rea-agents 6.5.0).

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4396 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation `build_reconstruction_obligation_ledger` closes an obligation when a manifest binding supplies a unique owner, required fixtures, and "a passing verifier whose authority is comparable to the original observation. The verifier must enumerate the obligation ID and its result must be present in the input Evidence bundle." (`docs/reconstruction-obligation-ledgers.md`). The verifier binding carries `command`, `authority`, `status: "pass"`, `result_evidence_id`, and `enumerated_obligation_ids`. Nothing in that binding shows the verifier can distinguish a correct reconstruction from a wrong one. A verifier that always passes, for example one that enumerates the obligation ID but asserts nothing, or one whose comparison silently skips the relevant dimension, meets the stated closure rule. The `negative` value of `obligationCaseKindSchema` (`src/domain/reconstructionObligationLedgerSchemas.ts`) describes negative inputs to the target's behavior ("reject an invalid configuration option"), not a negative control on the verifier itself. `verify_reconstruction` takes only a specification and checks claim authority; `evaluate_reconstruction_coverage` checks evidence provenance. REA already applies this discipline internally: `npm run verify:readiness` fails closed if "a deliberate primary divergence is not localized" and keeps "every deliberate fault" represented (`docs/reconstruction-readiness.md`). That protects REA's own comparators, not the verifiers a user binds into a ledger. ### Use cases - An agent reconstructs a protocol handler and writes a conformance test as the verifier. Before the ledger closes the obligation, it should show the same test failing against a build with one deliberate defect (wrong field order, dropped error path). - Reviewing someone else's reconstruction claim: the ledger shows which closures rest on verifiers that were demonstrated to fail on a known-wrong input and which were never challenged. Open false-green and false-red reports in the reconstruction area (#3937, #3984; closed #3980) show that closure logic is already a source of incorrect results; this request addresses the verifier side, which those issues do not cover. ### Desired outcome and success criteria Let a reconstruction obligation ledger record a negative control for each verifier binding (a deliberately wrong candidate and the verifier's observed failing result), and keep closure open or unknown when no control shows that the verifier can fail. - A verifier binding can include one or more controls, each naming the deliberately wrong candidate (by artifact identity or fixture), the defect it introduces, and the Evidence ID of the verifier's observed failing result. - The ledger reports, per obligation, whether its verifier has a passing result on the candidate and a failing result on at least one control; a control that also passes is reported as a vacuous verifier, not ignored. - Closure policy is explicit: an obligation without a demonstrated failing control does not report the same closed status as one with it (either it stays open or it closes with a named limitation; maintainers choose which). - Existing ledgers without controls still parse; their closures are labeled as unchallenged rather than silently upgraded or rejected. - Documentation explains how to construct a one-defect control and why a control that passes is evidence against the verifier. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) The ledger reads Evidence and manifests only; running the verifier and the control stays with the caller, as it does today for the passing result. Non-goals: REA generating mutants automatically, or running caller verifier commands. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) Possible fixture: a ledger with two obligations bound to the same trivially passing verifier, one with a control whose result also passes and one with a control that fails. Expected: the first is reported as a vacuous verifier and not closed; the second closes. ### Alternatives considered - Relying on reviewers to notice weak verifiers: does not scale and is not recorded in Evidence. - Expressing controls as additional `negative` cases: conflates target behavior with verifier sensitivity and would let a verifier that ignores its input satisfy both. ### Possible direction Model a control as an optional array on the verifier binding with its own `result_evidence_id` and expected `status: "fail"`, and surface the per-obligation result in the ledger output next to existing closure reasons. ### References - Checked against `main` at commit 8ab5024 (`rea-agents` 6.5.0).

bsakaguchi referenced this issue 2026-10-17 21:01:31 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi commented 2026-10-31 00:32:33 +00:00

Author

Owner

Copy link

@mhmdmhmdtahapnahy-star commented on GitHub (Oct 25, 2026):

Before submitting

• I searched the open and closed issues and pull requests for a related proposal.
• I understand the contribution scope must be reviewed before integration; open questions are welcome here.
• This request does not include credentials, private samples, or sensitive target data.

Area

Evidence, artifacts, or reconstruction

Current limitation

build_reconstruction_obligation_ledger closes an obligation when a manifest binding supplies a unique owner, required fixtures, and "a passing verifier whose authority is comparable to the original observation. The verifier must enumerate the obligation ID and its result must be present in the input Evidence bundle." (docs/reconstruction-obligation-ledgers.md). The verifier binding carries command, authority, status: "pass", result_evidence_id, and enumerated_obligation_ids.

Nothing in that binding shows the verifier can distinguish a correct reconstruction from a wrong one. A verifier that always passes, for example one that enumerates the obligation ID but asserts nothing, or one whose comparison silently skips the relevant dimension, meets the stated closure rule. The negative value of obligationCaseKindSchema (src/domain/reconstructionObligationLedgerSchemas.ts) describes negative inputs to the target's behavior ("reject an invalid configuration option"), not a negative control on the verifier itself. verify_reconstruction takes only a specification and checks claim authority; evaluate_reconstruction_coverage checks evidence provenance.

REA already applies this discipline internally: npm run verify:readiness fails closed if "a deliberate primary divergence is not localized" and keeps "every deliberate fault" represented (docs/reconstruction-readiness.md). That protects REA's own comparators, not the verifiers a user binds into a ledger.

Use cases

• An agent reconstructs a protocol handler and writes a conformance test as the verifier. Before the ledger closes the obligation, it should show the same test failing against a build with one deliberate defect (wrong field order, dropped error path).
• Reviewing someone else's reconstruction claim: the ledger shows which closures rest on verifiers that were demonstrated to fail on a known-wrong input and which were never challenged.

Open false-green and false-red reports in the reconstruction area (#3937, #3984; closed #3980) show that closure logic is already a source of incorrect results; this request addresses the verifier side, which those issues do not cover.

Desired outcome and success criteria

Let a reconstruction obligation ledger record a negative control for each verifier binding (a deliberately wrong candidate and the verifier's observed failing result), and keep closure open or unknown when no control shows that the verifier can fail.

• A verifier binding can include one or more controls, each naming the deliberately wrong candidate (by artifact identity or fixture), the defect it introduces, and the Evidence ID of the verifier's observed failing result.
• The ledger reports, per obligation, whether its verifier has a passing result on the candidate and a failing result on at least one control; a control that also passes is reported as a vacuous verifier, not ignored.
• Closure policy is explicit: an obligation without a demonstrated failing control does not report the same closed status as one with it (either it stays open or it closes with a named limitation; maintainers choose which).
• Existing ledgers without controls still parse; their closures are labeled as unchallenged rather than silently upgraded or rejected.
• Documentation explains how to construct a one-defect control and why a control that passes is evidence against the verifier.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

The ledger reads Evidence and manifests only; running the verifier and the control stays with the caller, as it does today for the passing result. Non-goals: REA generating mutants automatically, or running caller verifier commands.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

Possible fixture: a ledger with two obligations bound to the same trivially passing verifier, one with a control whose result also passes and one with a control that fails. Expected: the first is reported as a vacuous verifier and not closed; the second closes.

Alternatives considered

• Relying on reviewers to notice weak verifiers: does not scale and is not recorded in Evidence.
• Expressing controls as additional negative cases: conflates target behavior with verifier sensitivity and would let a verifier that ignores its input satisfy both.

Possible direction

Model a control as an optional array on the verifier binding with its own result_evidence_id and expected status: "fail", and surface the per-obligation result in the ledger output next to existing closure reasons.

References

• Checked against main at commit 8ab5024 (rea-agents 6.5.0).

<!-- gh-comment-id:6404783433 --> @mhmdmhmdtahapnahy-star commented on GitHub (Oct 25, 2026): > ### Before submitting > > - [x] I searched the open and closed issues and pull requests for a related proposal. > - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. > - [x] This request does not include credentials, private samples, or sensitive target data. > > ### Area > > Evidence, artifacts, or reconstruction > > ### Current limitation > > `build_reconstruction_obligation_ledger` closes an obligation when a manifest binding supplies a unique owner, required fixtures, and "a passing verifier whose authority is comparable to the original observation. The verifier must enumerate the obligation ID and its result must be present in the input Evidence bundle." (`docs/reconstruction-obligation-ledgers.md`). The verifier binding carries `command`, `authority`, `status: "pass"`, `result_evidence_id`, and `enumerated_obligation_ids`. > > Nothing in that binding shows the verifier can distinguish a correct reconstruction from a wrong one. A verifier that always passes, for example one that enumerates the obligation ID but asserts nothing, or one whose comparison silently skips the relevant dimension, meets the stated closure rule. The `negative` value of `obligationCaseKindSchema` (`src/domain/reconstructionObligationLedgerSchemas.ts`) describes negative inputs to the target's behavior ("reject an invalid configuration option"), not a negative control on the verifier itself. `verify_reconstruction` takes only a specification and checks claim authority; `evaluate_reconstruction_coverage` checks evidence provenance. > > REA already applies this discipline internally: `npm run verify:readiness` fails closed if "a deliberate primary divergence is not localized" and keeps "every deliberate fault" represented (`docs/reconstruction-readiness.md`). That protects REA's own comparators, not the verifiers a user binds into a ledger. > > ### Use cases > > - An agent reconstructs a protocol handler and writes a conformance test as the verifier. Before the ledger closes the obligation, it should show the same test failing against a build with one deliberate defect (wrong field order, dropped error path). > - Reviewing someone else's reconstruction claim: the ledger shows which closures rest on verifiers that were demonstrated to fail on a known-wrong input and which were never challenged. > > Open false-green and false-red reports in the reconstruction area (#3937, #3984; closed #3980) show that closure logic is already a source of incorrect results; this request addresses the verifier side, which those issues do not cover. > > ### Desired outcome and success criteria > > Let a reconstruction obligation ledger record a negative control for each verifier binding (a deliberately wrong candidate and the verifier's observed failing result), and keep closure open or unknown when no control shows that the verifier can fail. > > - A verifier binding can include one or more controls, each naming the deliberately wrong candidate (by artifact identity or fixture), the defect it introduces, and the Evidence ID of the verifier's observed failing result. > - The ledger reports, per obligation, whether its verifier has a passing result on the candidate and a failing result on at least one control; a control that also passes is reported as a vacuous verifier, not ignored. > - Closure policy is explicit: an obligation without a demonstrated failing control does not report the same closed status as one with it (either it stays open or it closes with a named limitation; maintainers choose which). > - Existing ledgers without controls still parse; their closures are labeled as unchallenged rather than silently upgraded or rejected. > - Documentation explains how to construct a one-defect control and why a control that passes is evidence against the verifier. > > ### Expected interaction with targets > > Read existing files or captured data > > ### Target and scope details (optional) > > The ledger reads Evidence and manifests only; running the verifier and the control stays with the caller, as it does today for the passing result. Non-goals: REA generating mutants automatically, or running caller verifier commands. > > ### Verification available so far > > I can suggest a sample or manual check > > ### Verification details (optional) > > Possible fixture: a ledger with two obligations bound to the same trivially passing verifier, one with a control whose result also passes and one with a control that fails. Expected: the first is reported as a vacuous verifier and not closed; the second closes. > > ### Alternatives considered > > - Relying on reviewers to notice weak verifiers: does not scale and is not recorded in Evidence. > - Expressing controls as additional `negative` cases: conflates target behavior with verifier sensitivity and would let a verifier that ignores its input satisfy both. > > ### Possible direction > > Model a control as an optional array on the verifier binding with its own `result_evidence_id` and expected `status: "fail"`, and surface the per-obligation result in the ledger output next to existing closure reasons. > > ### References > > - Checked against `main` at commit 8ab5024 (`rea-agents` 6.5.0). >

bsakaguchi commented 2026-10-31 00:32:33 +00:00

Author

Owner

Copy link

@morluto commented on GitHub (Oct 26, 2026):

Thank you for the concrete false-green example. #4991 and #7178 both propose negative-control closure rules; #6367 separately addresses control-content identity and depends on #4991. These proposals remain open while the closure policy and one compatible implementation are decided, including the current proof owner/revision requirements.

<!-- gh-comment-id:6428621436 --> @morluto commented on GitHub (Oct 26, 2026): Thank you for the concrete false-green example. #4991 and #7178 both propose negative-control closure rules; #6367 separately addresses control-content identity and depends on #4991. These proposals remain open while the closure policy and one compatible implementation are decided, including the current proof owner/revision requirements.

bsakaguchi referenced this issue 2026-10-31 00:55:10 +00:00

[PR #1759] [MERGED] fix(javascript): index repeated graph observations before final sorting #4799

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

codex/procedure-reference-stacked

release-please--branches--main--components--rea-agents

release-please--branches--main--components--rea-agents--release-notes

codex/kuna-independent-retry

codex/byte-search-overlay-coverage

codex/open-failure-target-receipt

codex/kuna-xref-evidence

codex/ghidra-ambiguous-procedure-recovery

codex/function-source-bundle

codex/trace-function-integration-prototype

codex/snapshot-source-closure

codex/recorded-evidence-array-pages

codex/evidence-recovery-redesign

codex/trace-feature-address-scope

codex/call-discovery-scope

codex/ghidra-literal-candidate-evidence

codex/decompile-directory-independent-retry

codex/retry-provenance-base

codex/value-flow-capability-experiment

codex/ghidra-containing-instruction

cursor/readme-discord-button-ef9f

dependabot/github_actions/actions/setup-node-7.1.0

dependabot/github_actions/actions/upload-artifact-7.0.2

dependabot/npm_and_yarn/npm-minor-and-patch-d8d97ce6df

codex/kuna-1989

fix/8559-native-ui-fixture-ownership

fix/8555-go-verifier-mcp-ownership

codex/provider-capability-recovery

fix/8642-rizin-target-stdin

codex/ghidra-memory-effect-scope

codex/ghidra-annotation-entry-selector

codex/ghidra-readonly-recovery

codex/ghidra-regex-verifier-recovery

codex/evidence-discovery-view-guidance

fix/8545-bulk-append-overflow

fix/8428-navigation-refusal-alternatives

codex/address-context-recovery

codex/matching-member-limitations

codex/unknown-scope-contract

codex/evidence-view-guidance

feat/8373-native-trace-views

codex/ghidra-snapshot-verifier-binding

codex/elf-export-visibility

codex/evidence-view-recovery

codex/native-reference-cli-help

codex/provider-candidate-observation-scope

codex/kuna-session-verification

codex/ghidra-switch-lifetime-guidance

codex/pseudocode-paging-discovery

codex/clarify-evidence-view-support

codex/kuna-xrefs-selector-recovery

codex/context-capacity-recovery

codex/evidence-closure-large-links

codex/same-function-evidence-identity

codex/ghidra-verifier-inspected-jdk

codex/audit-guided-workflows

codex/crash-prompt-retained-dossiers

codex/analysis-view-error-recovery

codex/kuna-verifier-target-selection

codex/ghidra-selected-project-call-coverage

codex/docs-native-analysis-scope

codex/ghidra-java-socket-boundary

codex/ghidra-retained-snapshot-verifier

codex/ghidra-search-inventory-facts

fix/8284-zero-argument-parameter-bindings

fix/8198-ui-action-handler-offset

fix/8257-elf-entry-label-identity

fix/8304-deferred-output-schema-projection

fix/8277-call-path-computed-target-uncertainty

fix/pr-8089-conflicts

fix/ci-static-duplicate-export

dependabot/npm_and_yarn/lint-staged-17.6.0

dependabot/github_actions/actions/download-artifact-8.0.2

dependabot/npm_and_yarn/write-file-atomic-8.0.0

dependabot/npm_and_yarn/canonicalize-5.1.0

dependabot/github_actions/actions/cache/restore-6.1.0

dependabot/npm_and_yarn/toon-format/toon-4.4.0

dependabot/github_actions/actions/deploy-pages-5.0.1

codex/review-fixes-pr-2403

codex/review-fixes-pr-2400

codex/process-terminal-width

codex/test-brittleness-cleanup

verify/7167-browser-connect-macos

fix/7167-browser-connect

feat/native-matching-allowance-setting

feat/browser-scenario-dry-run

test/managed-caller-parameters-20261024

codex/parser-fortythird-boundaries

fix/6926-pinvoke-platform-decorations-20261023

fix/6889-har-body-encoding-20261023

fix/6888-sqlite-schema-budget-20261023

fix/dependency-security-gates-6708

cursor/evidence-overwrite-rebase-b4ac

feat/4057-verify-native-exports

fix/windows-acl-observer-overhead-20261022

cursor/erlang-beam-restack-4476

cursor/pe-certificate-review-bf32

fix/6116-javascript-application-fs-errors

fix/6061-unmapped-runtime-script-unknown

feat/browser-scenario-summary

fix/pe-certificates

codex/verify-3407

cursor/rebase-5699

cursor/rebase-5352

cursor/rebase-5600

cursor/fix-cli-schema-omission-10a8

codex/audit-hopper-shutdown-reasons-20261021

fix/demangle-swift-omitted-record

fix/nib-boolean-value-types

cursor/cancellation-partial-observation-a5ac

fix/ib-object-limit-reasons

fix/electron-fuse-limit-advice

fix/kuna-doctor-dangling-cache

fix/fixed-budget-refusal-advice

fix/js-ipc-listener-dedup

fix/js-return-member-provenance

fix/dmg-integrity-retry-advice

fix/ida-doctor-readiness

fix/kuna-version-probe-output-drain

fix/legacy-swift-runtime-name-matching

fix/dylib-lazy-load-commands

fix/browser-scenario-startup-cancel

fix/swift-nested-punycode-classification

fix/compare-unselected-scopes

fix/objc-method-budget-coverage

fix/dmg-mounted-root-observations

audit/ci-tests-20261019-round2

release/6.7.0

fix/wabt-cleanup-retry-resolution

fix/electron-fuse-elf-pe-architecture

fix/native-plist-descriptor-ownership

fix/kuna-caller-cleanup-ownership

experiment/atomic-codemode-20261016

review/first-contributor-3776

fix/call-resolution-full-read-cycles

fix/member-mutation-selection-repeat

experiment/atomic-re-tools-20261015

perf/member-mutation-lazy-origins

perf/static-network-mutation-index

fix/hopper-startup-lifecycle

audit/3050-windows-proof-20261015

feat/windows-window-capture-2183

audit/3049-windows-proof-20261015

audit/3735-macos-fixtures-20261015

fix/batch-decompile-null-pseudocode

fix/kuna-inventory-honors-jobs

experiment/browser-codemode-tool-design-20261015

fix/hopper-clean-runtime-argv

codex/review-2049-27f1b367

review-fixes/pr-2787-routing

fix/3360-scoped-this-emitters

fix/3367-replaced-global-effects

fix/3838-compact-any-value-items

test/hopper-download-probe-20261015

codex/windows-runtime-creation-red-green-20261015

codex/windows-readonly-root-red-green-20261015

codex/windows-root-share-red-green-20261015

codex/exp-1685-win-mcp-startup

codex/bug-sweep-20261015

investigate/2190-windows-package-phases

investigate/3543-macos-cli-deadline

perf/3281-reverse-tools-feedback-quality

fix/3406-hopper-doctor-fixture

fix/3341-wrapper-require-test-context

fix/3301-owned-uninstall-fixtures

fix/3164-compiler-input-ownership

fix/pcap-cleanup-stdout-newline-20261014

perf/interface-builder-summary

codex/review-fixes-pr-1977

fix/ghidra-effective-jvm-platform

fix/docs-turkish-rust-link-20261013

fix/main-maintenance-ci-20261010

fix/recover-binary-session-process-effects

codex/review-fixes-pr-2457

codex/ci-required-cancellation-gate

fix/main-format-baseline-20261013

fix/setup-preserve-entry-fields

cursor/restore-main-checks-1ffc

fix/ghidra-bridge-hashmap-import

codex/shared-ci-jadx-json-default-20261013

codex/shared-ci-ghidra-test-groups-20261013

codex/shared-ci-java-fixture-format-20261013

codex/fix-intrinsic-invocation-boundaries

test/release-preflight-reusable-jobs

test/js-parameter-provenance-expectation

fix/linux-hopper-verification-current

test/2419-ghidra-elf-probe-size

followup/pr-1544-native-ida

codex/fold-pr-2230-contribution

docs/readme-responsible-use

fix/issue-2064

fix/issue-2050

fix/issue-2053

fix/issue-1968

fix/issue-1945

experiment/codemode-bridge-20261011

fix/tool-effects-negative-wording-1904-20261012

fix/1842-electron-interop-provenance

feat/recover-javascript-multi-input

refactor/website-i18n-prep

fix/nativeaot-pe-virtual-extent

fix/browser-verifier-ci-hang

fix/pe-resources-input-selection

docs/beginner-friendly-guides

docs/beginner-setup-guide

fix/javascript-analysis-worker-1563

fix/1649-ghidra-duplicate-names

fix/javascript-export-keys-integration-1369

test/maintenance-boundary-contracts-20261011

review/javascript-export-keys-1369

review/process-live-progress-1483

test/javascript-1495-growth-ratio

fix/ci-escape-timing

docs/normalized-terminal-geometry-1450

release/6.3.0

archive/release-6.3.0-pr1381

release/6.2.0

fix/electron-preload-dynamic-override

fix/javascript-self-referential-bundler-edges

release/6.1.0

cursor/grok-client-cherry-pick-0b56

feat/signature-posture

feat/dyld-shared-cache

feat/artifact-integrity-policy

feat/pkg-inventory

release/6.0.0

chore/sync-release-5.0.0

release/5.0.0

cursor/cloud-agent-node-787e

fix/javascript-xhr-open-endpoints

review/pr-711-realpath-fallback-wording

cleanup/replay-confinement

codex/test-suite-performance

codex/issue-foundations

codex/address-open-issues-2026-07-20

agent/javascript-vite-rollup-esbuild-adapters

agent/process-cleanup

agent/triage-integration

agent/unknown-commands-registry

feat/mcp-identity-metadata

morlvps/issue_cleanup

codex/installer-redesign

morl/roadmap-investigation-core

morl/roadmap-investigation-docs

release-please--branches--main--components--rea

rea-agents-6.8.0

rea-agents-6.7.0

rea-agents-6.6.0

experiment/atomic-codemode-wait-runtime-20261016

rea-agents-6.5.0

rea-agents-6.4.0

rea-agents-6.3.0

rea-agents-6.2.0

rea-agents-6.1.0

rea-agents-6.0.0

rea-agents-5.0.0

rea-agents-4.1.0

rea-agents-4.0.1

rea-agents-4.0.0

rea-agents-3.2.1

rea-agents-3.2.0

rea-agents-3.1.0

rea-agents-3.0.0

rea-agents-2.7.0

rea-agents-2.6.0

rea-agents-2.5.1

rea-agents-2.5.0

rea-agents-2.4.0

rea-agents-2.3.0

rea-agents-2.2.0

rea-agents-2.1.0

rea-agents-2.0.0

rea-agents-1.7.0

rea-agents-1.6.0

rea-agents-1.5.0

rea-agents-1.4.0

rea-agents-1.3.0

rea-agents-1.2.0

rea-agents-1.1.0

rea-agents-1.0.0

rea-agents-0.5.0

rea-agents-0.4.0

rea-agents-0.3.0

rea-0.2.1

rea-0.2.0

Labels

Clear labels   

area: bridge

  

area: bridge

  

area: build

  

area: build

  

area: build

  

area: cli

  

area: domain

  

area: evidence

  

area: mcp

  

area: native

  

area: providers

  

area: runtime

  

area: server

  

area: setup

  

area: tests

  

bug

  

design

  

documentation

  

enhancement

  

enhancement

  

enhancement

  

experiment

  

help wanted

  

i18n

  

invalid

  

P0: critical

  

P1: high

  

P2: medium

  

P2: medium

  

P2: medium

  

P3: low

  

performance

  

provider-request

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

roadmap

  

triage

No labels

area: bridge

area: bridge

area: build

area: build

area: build

area: cli

area: domain

area: evidence

area: mcp

area: native

area: providers

area: runtime

area: server

area: setup

area: tests

bug

design

documentation

enhancement

enhancement

enhancement

experiment

help wanted

i18n

invalid

P0: critical

P1: high

P2: medium

P2: medium

P2: medium

P3: low

performance

provider-request

pull-request

question

roadmap

triage

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1748

No description provided.