[GH-ISSUE #7412] [Bug] build-reconstruction-obligation-ledger lets a passing fixture entry hide an applicable failed proof #4419

New issue

Closed

opened 2026-10-31 00:49:38 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:49:38 +00:00

Owner

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

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

The public build-reconstruction-obligation-ledger CLI returned status: "ready" and obligation status verified, with no diagnostics, for a required positive case with two selected fixture entries: one applicable proof passes and the other fails. Both proofs remain retained in the returned binding and Evidence links. The failure still disappears if the entries are reversed or use different fixture IDs for the required case kind.

The failed proof alone produces fixture-failed and a failed ledger. Putting both same-pair proof IDs into one fixture entry also produces a failed ledger. These controls show that the failed proof is applicable and that splitting the selected proofs across entries changes the closure result.

Reproduction

Use the specified source baseline with its locked dependencies and built runtime already present, and Node 24 on PATH. From the checkout root, run the following to create an empty working directory, inline synthetic Evidence and an isolated home. The owner path and verifier command are descriptive input data; no target or declared verifier command executes.

export REPO="$PWD"
work="$(mktemp -d)"
cd "$work"
mkdir home
cat > generate.mjs <<'JS'
import { writeFileSync } from 'node:fs';
import { pathToFileURL } from 'node:url';
const repo = process.env.REPO;
const { createEvidence } = await import(pathToFileURL(`${repo}/dist/domain/evidence.js`));
const { createEvidenceBundle } = await import(pathToFileURL(`${repo}/dist/domain/evidenceBundle.js`));
const provider = { id: 'synthetic', name: 'Synthetic ledger check', version: '1' };
const obligationId = 'review.fixture-outcomes';
const owner = '3'.repeat(64);
const review = createEvidence(undefined, provider, {
  operation: 'review', parameters: {}, result: { reviewed: true },
  confidence: 'observed', authority: 'shipped-artifact',
});
const makeProof = (fixtureId, passed) => createEvidence(undefined, provider, {
  predicateType: 'rea.reconstruction-proof', operation: 'verify_reconstruction_obligations',
  parameters: {}, confidence: 'observed', authority: 'controlled-replay',
  result: { bindings: [{ obligation_id: obligationId, obligation_version: 1, owner_sha256: owner,
    fixtures: [{ fixture_id: fixtureId, case_kind: 'positive', passed }],
    verifiers: [{ verifier_id: 'verifier.check', claim_id: 'claim.check', passed: true }],
  }] },
});
const good = makeProof('fixture.shared', true);
const bad = makeProof('fixture.shared', false);
const otherBad = makeProof('fixture.failed', false);
const fixture = (id, evidence) => ({ fixture_id: id, case_kind: 'positive', authority: 'unit', evidence_ids: [evidence.evidence_id] });
const request = {
  evidence_bundle: createEvidenceBundle([review, good, bad, otherBad]),
  reviewed_obligations: [{ obligation_id: obligationId, obligation_version: 1, title: 'Honor every selected fixture outcome',
    application_layer: 'other', family: 'synthetic', target: { artifact_sha256: null, application_node_id: null, semantic_node_id: null, location: 'fixture check' },
    required: true, required_case_kinds: ['positive'], required_original_authority: 'static', required_fixture_authority: 'unit', required_verifier_authority: 'unit',
    requires_parser_type: false, dependency_obligation_ids: [], residual_unknown_ids: [], unavailable_authority: [], required_next_evidence: [], disposition: 'active', review_evidence_ids: [review.evidence_id],
  }],
  manifest: { bindings: [{ obligation_id: obligationId,
    owner: { module_path: 'sample.ts', symbol: 'check', owner_sha256: owner }, parser_type: null,
    original_cases: [{ kind: 'positive', evidence_id: review.evidence_id, location: 'review' }], fixtures: [],
    verifier: { verifier_id: 'verifier.check', claim_id: 'claim.check', command: 'node check.mjs', authority: 'unit', status: 'pass', result_evidence_id: good.evidence_id,
      enumerated_obligation_ids: [obligationId], nondeterminism: { mode: 'total-order', specification: 'One result' } },
  }], contradictions: [] },
};
const passing = fixture('fixture.shared', good);
const failing = fixture('fixture.shared', bad);
const variants = {
  mixed: [passing, failing],
  reversed: [failing, passing],
  distinct: [passing, fixture('fixture.failed', otherBad)],
  failedOnly: [failing],
  passedOnly: [passing],
  combined: [{ ...passing, evidence_ids: [good.evidence_id, bad.evidence_id] }],
};
for (const [name, fixtures] of Object.entries(variants)) {
  const input = structuredClone(request);
  input.manifest.bindings[0].fixtures = fixtures;
  writeFileSync(`${name}.json`, JSON.stringify(input));
}
writeFileSync('proof-ids.json', JSON.stringify({ good: good.evidence_id, bad: bad.evidence_id, otherBad: otherBad.evidence_id }));
JS
cat > run.mjs <<'JS'
import { readFileSync, writeFileSync } from 'node:fs';
import { spawnSync } from 'node:child_process';
const repo = process.env.REPO;
for (const name of ['mixed', 'mixed', 'mixed', 'reversed', 'distinct', 'failedOnly', 'passedOnly', 'combined']) {
  const run = spawnSync(process.execPath, [`${repo}/scripts/rea.mjs`, 'build-reconstruction-obligation-ledger', `${name}.json`, '--json'], {
    env: { PATH: process.env.PATH, HOME: `${process.cwd()}/home`, NO_COLOR: '1' }, encoding: 'utf8',
  });
  writeFileSync(`${name}.stdout.json`, run.stdout);
  writeFileSync(`${name}.stderr.txt`, run.stderr);
  const ledger = JSON.parse(run.stdout).normalized_result;
  const o = ledger.obligations[0];
  const request = JSON.parse(readFileSync(`${name}.json`));
  const failedIds = new Set(request.evidence_bundle.records.filter(r => r.normalized_result.bindings?.some(b => b.fixtures.some(f => !f.passed))).map(r => r.evidence_id));
  console.log(JSON.stringify({ name, exit: run.status, status: ledger.status, coverage: ledger.coverage.status, obligation: o.status, diagnostics: o.diagnostics.map(d => d.code),
    fixtures: o.binding.fixtures.length, retainedFailedProofs: ledger.evidence_links.filter(id => failedIds.has(id)).length }));
}
JS
env HOME="$PWD/home" node generate.mjs
env HOME="$PWD/home" node run.mjs

Compare the three mixed results with failedOnly and combined. Each subprocess executes node "$REPO/scripts/rea.mjs" build-reconstruction-obligation-ledger NAME.json --json and writes its full reply to the corresponding relative output file. The exact reduced output from the primary execution is below.

{"name":"mixed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1}
{"name":"mixed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1}
{"name":"mixed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1}
{"name":"reversed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1}
{"name":"distinct","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1}
{"name":"failedOnly","exit":0,"status":"failed","coverage":"complete","obligation":"implemented","diagnostics":["fixture-failed"],"fixtures":1,"retainedFailedProofs":1}
{"name":"passedOnly","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":1,"retainedFailedProofs":0}
{"name":"combined","exit":0,"status":"failed","coverage":"complete","obligation":"implemented","diagnostics":["fixture-failed"],"fixtures":1,"retainedFailedProofs":1}

Observe that all five mixed-entry calls report ready and verified despite one selected failed proof. The primary matrix repeated the same-pair mixed case three times, with three incorrect results. Each remaining variant ran once. A separate replay of this complete inline reproduction repeated the eight calls with the same outcomes.

Expected behavior

Under docs/reconstruction-obligation-ledgers.md, Manifest and closure → Proof applicability, lines 402-403: "An applicable false outcome produces fixture-failed or verifier-failed and a failed required ledger." Lines 389-395 require exact fixture-pair, owner and revision matching and require every selected claim to pass. Both entries select matching proof for the required positive case; the failed-only control confirms that the false result is applicable. A passing entry must not suppress the failing entry's diagnostic or turn the required obligation into verified closure.

Impact and scope

Observed impact is an incorrect affirmative verification result for this synthetic required obligation: all five mixed-entry calls retained the failed proof but returned ready without a diagnostic. The complete replay repeated those results. No downstream use, stored-data loss, target execution or production frequency was observed. MCP, generated obligation families, other case kinds and other platforms were not exercised.

For the repeated fixture pair, combining its two proof IDs into one entry is a demonstrated workaround that preserves both selected proofs and returns failed with fixture-failed. This control does not establish a workaround for the distinct-ID variant. A complete coverage status appeared in both incorrect mixed results and correctly failed controls, so no separate coverage-status defect is claimed.

REA version

6.8.0 (source commit a905a71e31)

Runtime and platform

Node 24.22.1; macOS 27.0.1 arm64.

Target and artifact context

Four synthetic authenticated Evidence records: a shipped-artifact review and three controlled-replay proof records, with one reviewed required obligation, one implementation digest and revision, and a positive case kind. One proof passes, one fails for the same fixture pair, and another fails for a distinct fixture ID. No analysis provider or target was opened.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

The JSON lines in Reproduction are observed projections of actual public CLI replies. Every invocation exited 0. retainedFailedProofs counts Evidence links whose retained input record explicitly reports a false fixture outcome. The full replies also retain those IDs in the selected fixture entries. The failed-only and combined controls return the exact diagnostic {"code":"fixture-failed","detail":"positive fixture proof qualification: failed-proof."}.

Source-only explanation, not a fix execution: src/application/ReconstructionObligationLedgerEvaluation.ts:275 filters fixture entries for each required kind, and line 306 accepts that kind when any qualified entry succeeds. The continue at line 312 skips the failure diagnostics at line 325. Exact proof qualification at src/application/ReconstructionObligationAuthority.ts:124 checks obligation, owner, revision and fixture pair, and line 154 rejects false outcomes. The schema accepts multiple fixture entries at src/domain/reconstructionObligationLedgerSchemas.ts:167.

An additional observed execution of the pinned source service reproduced mixed ready/verified and failed-only/combined failed/implemented using the same request files. It imported the production workflow at src/application/ReconstructionObligationLedgerService.ts:21 through the locked source loader. No build or full test suite was run. The package registry reported latest published rea-agents version 6.8.0, matching the baseline package version; the separately installed published-package runtime was not tested.

Typed outcome or recovery expected

For either mixed fixture order, retain the failed proof, emit fixture-failed, keep the required obligation below verified, and report ledger status failed. Preserve the passing-only control and the existing failed-only and combined-proof behavior.

Analysis or suspected cause

Source-derived: each entry is qualified correctly, but the case-kind aggregation uses an existential test across entries. Failure collection only executes if no entry succeeds. With no remaining diagnostics, src/application/ReconstructionObligationLedgerEvaluation.ts:513 selects verified; src/domain/reconstructionObligationLedgerIntegrity.ts:70 finds no required open obligation and line 84 selects ready. The observed result is therefore specific to aggregation across selected entries rather than Evidence authentication or exact-claim matching.

Additional context

Open #7338 concerns a diagnosed missing reference on an optional obligation; this input is required, every selected reference resolves, and no failed-proof diagnostic survives. Open #7330 concerns canonical-order import error wording. Open #4396 and its verifier-control proposals concern proving verifier sensitivity, rather than honoring an already-failed applicable fixture.

Closed #3363 and #6770 concern absent Evidence references, closed #6854 concerns mismatched owner proof, and closed #5925 concerns contradiction-entry grouping. Their triggers and restoration criteria differ. The same-kind missing-reference fix is already merged into the tested baseline, yet the present failed-proof input still reproduces. Open and closed issue searches, the supplied complete issue index, and related pull-request searches found no exact open duplicate of this failed-fixture aggregation behavior.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7412 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior The public `build-reconstruction-obligation-ledger` CLI returned `status: "ready"` and obligation status `verified`, with no diagnostics, for a required positive case with two selected fixture entries: one applicable proof passes and the other fails. Both proofs remain retained in the returned binding and Evidence links. The failure still disappears if the entries are reversed or use different fixture IDs for the required case kind. The failed proof alone produces `fixture-failed` and a failed ledger. Putting both same-pair proof IDs into one fixture entry also produces a failed ledger. These controls show that the failed proof is applicable and that splitting the selected proofs across entries changes the closure result. ### Reproduction 1. Use the specified source baseline with its locked dependencies and built runtime already present, and Node 24 on PATH. From the checkout root, run the following to create an empty working directory, inline synthetic Evidence and an isolated home. The owner path and verifier command are descriptive input data; no target or declared verifier command executes. ```sh export REPO="$PWD" work="$(mktemp -d)" cd "$work" mkdir home cat > generate.mjs <<'JS' import { writeFileSync } from 'node:fs'; import { pathToFileURL } from 'node:url'; const repo = process.env.REPO; const { createEvidence } = await import(pathToFileURL(`${repo}/dist/domain/evidence.js`)); const { createEvidenceBundle } = await import(pathToFileURL(`${repo}/dist/domain/evidenceBundle.js`)); const provider = { id: 'synthetic', name: 'Synthetic ledger check', version: '1' }; const obligationId = 'review.fixture-outcomes'; const owner = '3'.repeat(64); const review = createEvidence(undefined, provider, { operation: 'review', parameters: {}, result: { reviewed: true }, confidence: 'observed', authority: 'shipped-artifact', }); const makeProof = (fixtureId, passed) => createEvidence(undefined, provider, { predicateType: 'rea.reconstruction-proof', operation: 'verify_reconstruction_obligations', parameters: {}, confidence: 'observed', authority: 'controlled-replay', result: { bindings: [{ obligation_id: obligationId, obligation_version: 1, owner_sha256: owner, fixtures: [{ fixture_id: fixtureId, case_kind: 'positive', passed }], verifiers: [{ verifier_id: 'verifier.check', claim_id: 'claim.check', passed: true }], }] }, }); const good = makeProof('fixture.shared', true); const bad = makeProof('fixture.shared', false); const otherBad = makeProof('fixture.failed', false); const fixture = (id, evidence) => ({ fixture_id: id, case_kind: 'positive', authority: 'unit', evidence_ids: [evidence.evidence_id] }); const request = { evidence_bundle: createEvidenceBundle([review, good, bad, otherBad]), reviewed_obligations: [{ obligation_id: obligationId, obligation_version: 1, title: 'Honor every selected fixture outcome', application_layer: 'other', family: 'synthetic', target: { artifact_sha256: null, application_node_id: null, semantic_node_id: null, location: 'fixture check' }, required: true, required_case_kinds: ['positive'], required_original_authority: 'static', required_fixture_authority: 'unit', required_verifier_authority: 'unit', requires_parser_type: false, dependency_obligation_ids: [], residual_unknown_ids: [], unavailable_authority: [], required_next_evidence: [], disposition: 'active', review_evidence_ids: [review.evidence_id], }], manifest: { bindings: [{ obligation_id: obligationId, owner: { module_path: 'sample.ts', symbol: 'check', owner_sha256: owner }, parser_type: null, original_cases: [{ kind: 'positive', evidence_id: review.evidence_id, location: 'review' }], fixtures: [], verifier: { verifier_id: 'verifier.check', claim_id: 'claim.check', command: 'node check.mjs', authority: 'unit', status: 'pass', result_evidence_id: good.evidence_id, enumerated_obligation_ids: [obligationId], nondeterminism: { mode: 'total-order', specification: 'One result' } }, }], contradictions: [] }, }; const passing = fixture('fixture.shared', good); const failing = fixture('fixture.shared', bad); const variants = { mixed: [passing, failing], reversed: [failing, passing], distinct: [passing, fixture('fixture.failed', otherBad)], failedOnly: [failing], passedOnly: [passing], combined: [{ ...passing, evidence_ids: [good.evidence_id, bad.evidence_id] }], }; for (const [name, fixtures] of Object.entries(variants)) { const input = structuredClone(request); input.manifest.bindings[0].fixtures = fixtures; writeFileSync(`${name}.json`, JSON.stringify(input)); } writeFileSync('proof-ids.json', JSON.stringify({ good: good.evidence_id, bad: bad.evidence_id, otherBad: otherBad.evidence_id })); JS cat > run.mjs <<'JS' import { readFileSync, writeFileSync } from 'node:fs'; import { spawnSync } from 'node:child_process'; const repo = process.env.REPO; for (const name of ['mixed', 'mixed', 'mixed', 'reversed', 'distinct', 'failedOnly', 'passedOnly', 'combined']) { const run = spawnSync(process.execPath, [`${repo}/scripts/rea.mjs`, 'build-reconstruction-obligation-ledger', `${name}.json`, '--json'], { env: { PATH: process.env.PATH, HOME: `${process.cwd()}/home`, NO_COLOR: '1' }, encoding: 'utf8', }); writeFileSync(`${name}.stdout.json`, run.stdout); writeFileSync(`${name}.stderr.txt`, run.stderr); const ledger = JSON.parse(run.stdout).normalized_result; const o = ledger.obligations[0]; const request = JSON.parse(readFileSync(`${name}.json`)); const failedIds = new Set(request.evidence_bundle.records.filter(r => r.normalized_result.bindings?.some(b => b.fixtures.some(f => !f.passed))).map(r => r.evidence_id)); console.log(JSON.stringify({ name, exit: run.status, status: ledger.status, coverage: ledger.coverage.status, obligation: o.status, diagnostics: o.diagnostics.map(d => d.code), fixtures: o.binding.fixtures.length, retainedFailedProofs: ledger.evidence_links.filter(id => failedIds.has(id)).length })); } JS env HOME="$PWD/home" node generate.mjs env HOME="$PWD/home" node run.mjs ``` 2. Compare the three `mixed` results with `failedOnly` and `combined`. Each subprocess executes `node "$REPO/scripts/rea.mjs" build-reconstruction-obligation-ledger NAME.json --json` and writes its full reply to the corresponding relative output file. The exact reduced output from the primary execution is below. ```json {"name":"mixed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1} {"name":"mixed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1} {"name":"mixed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1} {"name":"reversed","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1} {"name":"distinct","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":2,"retainedFailedProofs":1} {"name":"failedOnly","exit":0,"status":"failed","coverage":"complete","obligation":"implemented","diagnostics":["fixture-failed"],"fixtures":1,"retainedFailedProofs":1} {"name":"passedOnly","exit":0,"status":"ready","coverage":"complete","obligation":"verified","diagnostics":[],"fixtures":1,"retainedFailedProofs":0} {"name":"combined","exit":0,"status":"failed","coverage":"complete","obligation":"implemented","diagnostics":["fixture-failed"],"fixtures":1,"retainedFailedProofs":1} ``` 3. Observe that all five mixed-entry calls report ready and verified despite one selected failed proof. The primary matrix repeated the same-pair mixed case three times, with three incorrect results. Each remaining variant ran once. A separate replay of this complete inline reproduction repeated the eight calls with the same outcomes. ### Expected behavior Under `docs/reconstruction-obligation-ledgers.md`, Manifest and closure → Proof applicability, lines 402-403: "An applicable false outcome produces `fixture-failed` or `verifier-failed` and a failed required ledger." Lines 389-395 require exact fixture-pair, owner and revision matching and require every selected claim to pass. Both entries select matching proof for the required positive case; the failed-only control confirms that the false result is applicable. A passing entry must not suppress the failing entry's diagnostic or turn the required obligation into verified closure. ### Impact and scope Observed impact is an incorrect affirmative verification result for this synthetic required obligation: all five mixed-entry calls retained the failed proof but returned ready without a diagnostic. The complete replay repeated those results. No downstream use, stored-data loss, target execution or production frequency was observed. MCP, generated obligation families, other case kinds and other platforms were not exercised. For the repeated fixture pair, combining its two proof IDs into one entry is a demonstrated workaround that preserves both selected proofs and returns failed with `fixture-failed`. This control does not establish a workaround for the distinct-ID variant. A complete coverage status appeared in both incorrect mixed results and correctly failed controls, so no separate coverage-status defect is claimed. ### REA version 6.8.0 (source commit a905a71e31f71457cb21fd056b234f872126974e) ### Runtime and platform Node 24.22.1; macOS 27.0.1 arm64. ### Target and artifact context Four synthetic authenticated Evidence records: a shipped-artifact review and three controlled-replay proof records, with one reviewed required obligation, one implementation digest and revision, and a positive case kind. One proof passes, one fails for the same fixture pair, and another fails for a distinct fixture ID. No analysis provider or target was opened. ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence The JSON lines in Reproduction are observed projections of actual public CLI replies. Every invocation exited 0. `retainedFailedProofs` counts Evidence links whose retained input record explicitly reports a false fixture outcome. The full replies also retain those IDs in the selected fixture entries. The failed-only and combined controls return the exact diagnostic `{"code":"fixture-failed","detail":"positive fixture proof qualification: failed-proof."}`. Source-only explanation, not a fix execution: `src/application/ReconstructionObligationLedgerEvaluation.ts:275` filters fixture entries for each required kind, and line 306 accepts that kind when any qualified entry succeeds. The `continue` at line 312 skips the failure diagnostics at line 325. Exact proof qualification at `src/application/ReconstructionObligationAuthority.ts:124` checks obligation, owner, revision and fixture pair, and line 154 rejects false outcomes. The schema accepts multiple fixture entries at `src/domain/reconstructionObligationLedgerSchemas.ts:167`. An additional observed execution of the pinned source service reproduced mixed ready/verified and failed-only/combined failed/implemented using the same request files. It imported the production workflow at `src/application/ReconstructionObligationLedgerService.ts:21` through the locked source loader. No build or full test suite was run. The package registry reported latest published `rea-agents` version 6.8.0, matching the baseline package version; the separately installed published-package runtime was not tested. ### Typed outcome or recovery expected For either mixed fixture order, retain the failed proof, emit `fixture-failed`, keep the required obligation below verified, and report ledger status failed. Preserve the passing-only control and the existing failed-only and combined-proof behavior. ### Analysis or suspected cause Source-derived: each entry is qualified correctly, but the case-kind aggregation uses an existential test across entries. Failure collection only executes if no entry succeeds. With no remaining diagnostics, `src/application/ReconstructionObligationLedgerEvaluation.ts:513` selects verified; `src/domain/reconstructionObligationLedgerIntegrity.ts:70` finds no required open obligation and line 84 selects ready. The observed result is therefore specific to aggregation across selected entries rather than Evidence authentication or exact-claim matching. ### Additional context Open [#7338](https://github.com/morluto/rea/issues/7338) concerns a diagnosed missing reference on an optional obligation; this input is required, every selected reference resolves, and no failed-proof diagnostic survives. Open [#7330](https://github.com/morluto/rea/issues/7330) concerns canonical-order import error wording. Open [#4396](https://github.com/morluto/rea/issues/4396) and its verifier-control proposals concern proving verifier sensitivity, rather than honoring an already-failed applicable fixture. Closed [#3363](https://github.com/morluto/rea/issues/3363) and [#6770](https://github.com/morluto/rea/issues/6770) concern absent Evidence references, closed [#6854](https://github.com/morluto/rea/issues/6854) concerns mismatched owner proof, and closed [#5925](https://github.com/morluto/rea/issues/5925) concerns contradiction-entry grouping. Their triggers and restoration criteria differ. The same-kind missing-reference fix is already merged into the tested baseline, yet the present failed-proof input still reproduces. Open and closed issue searches, the supplied complete issue index, and related pull-request searches found no exact open duplicate of this failed-fixture aggregation behavior.

bsakaguchi closed this issue

2026-10-31 00:49:38 +00:00

bsakaguchi referenced this issue

2026-10-31 01:12:51 +00:00

[PR #4419] [CLOSED] fix(setup): install the DeepSeek Harness skill in the client's own root #6229