[GH-ISSUE #405] Emit reconstruction obligation ledgers and verify coverage closure #249

Closed
opened 2026-10-15 18:22:58 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Jul 22, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/405

Problem

REA can produce application graphs, Evidence v2 records, comparisons, process captures, and reconstruction verification for finite claims. What is missing is a machine-readable closure model that answers:

Which observed behaviors and boundaries have an owned reconstructed implementation and verifier, and which obligations remain open?

Without this, a reconstruction can accumulate many green component tests while still lacking an executable owner for a command, parser, persistence format, runtime lifecycle, or negative path.

Proposal

Add a Reconstruction Obligation Ledger derived from authenticated static/runtime Evidence plus an explicitly supplied reconstruction manifest.

Each obligation should represent one finite claim, not global application equivalence.

Obligation record

An obligation should include:

  • stable obligation ID and version;
  • authority Evidence IDs and exact locations;
  • target artifact/application-graph node;
  • boundary or behavior family;
  • observed positive, negative, malformed, cancellation, and teardown cases;
  • reconstructed owning module and symbol;
  • parser/schema/domain type where applicable;
  • fixture IDs and fixture authority;
  • verifier command/claim ID and latest result Evidence;
  • allowed nondeterminism/partial-order specification;
  • dependencies on other obligations;
  • status: unowned, characterized, implemented, verified, contradicted, blocked, out-of-scope, or unknown;
  • residual unknowns, unavailable authority, and required next evidence.

Coverage generation

Candidate obligations may be generated from:

  • CLI commands/options/errors;
  • REST/GraphQL/Phoenix/WebSocket/JSON-RPC/MCP endpoints and schemas;
  • IPC/contextBridge/preload/native-addon boundaries;
  • persisted paths/formats/migrations;
  • process roles, signals, children, and cleanup;
  • routes, operations, UI states, and desktop bridge calls;
  • native exports and ABI surfaces;
  • application-version deltas;
  • runtime capture events and negative outcomes.

Generation must be conservative. A static literal establishes a candidate obligation, not runtime reachability. One-sided evidence cannot prove behavioral absence.

Closure rules

  • verified requires comparable authority and reconstruction evidence for the declared finite claim.
  • A module existing is not proof it owns the behavior.
  • A unit test is insufficient when the obligation is process-, packaging-, renderer-, ABI-, or protocol-level.
  • Missing negative coverage remains open when malformed/error behavior is part of the boundary.
  • A broad verifier cannot silently satisfy obligations it does not enumerate.
  • Unknown, blocked, waived, and out-of-scope obligations remain visible and cannot count as verified.
  • Every completion report must enumerate all obligations and prove zero required open items.

Outputs

  • canonical JSON ledger;
  • summary grouped by application layer and evidence authority;
  • dependency/ownership graph;
  • missing-owner and missing-verifier report;
  • contradiction report;
  • residual-unknown ledger;
  • deterministic closure digest;
  • portable Evidence v2/resource representation.

Acceptance criteria

  • A versioned schema defines obligations, ownership, evidence, fixtures, verifier claims, dependencies, and residuals.
  • A generator can derive conservative candidate obligations from JavaScript Application Graph and runtime/process Evidence.
  • Users can add reviewed obligations without pretending they were automatically observed.
  • Reconstruction manifests bind modules/symbols and fixture/verifier IDs to obligations.
  • Closure verification fails on missing owner, parser/type, negative fixture, verifier result, or comparable authority.
  • Static-only candidates remain static and cannot be upgraded to observed behavior implicitly.
  • Duplicate and ambiguous ownership fails closed.
  • Contradictory evidence reopens or fails the affected obligation.
  • Results are deterministic, pageable, Evidence v2-backed, and exportable as MCP resources.
  • CLI and MCP expose identical structured summaries and typed per-obligation diagnostics.
  • Fixtures demonstrate that green unit tests cannot close an unexercised packaged-process obligation.
  • Documentation gives complete examples for CLI, protocol, Electron, persistence, and native ABI reconstruction.

Relationship to existing work

  • Builds on JavaScript Application Graph, JavaScript runtime semantic tracing in #404, and static/runtime reconciliation.
  • Consumes Process Capture v4 and comparison Evidence.
  • Complements verify_reconstruction; it supplies the finite specification and proves specification coverage rather than claiming global equivalence.
  • Portable output should align with #336.

Non-goals

  • Automatically claiming a whole application has been cloned.
  • Inventing obligations for unavailable private server internals.
  • Treating source-file or test counts as behavioral coverage.
  • Allowing waivers to disappear from completion reports.
Originally created by @morluto on GitHub (Jul 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/405 ## Problem REA can produce application graphs, Evidence v2 records, comparisons, process captures, and reconstruction verification for finite claims. What is missing is a machine-readable closure model that answers: > Which observed behaviors and boundaries have an owned reconstructed implementation and verifier, and which obligations remain open? Without this, a reconstruction can accumulate many green component tests while still lacking an executable owner for a command, parser, persistence format, runtime lifecycle, or negative path. ## Proposal Add a Reconstruction Obligation Ledger derived from authenticated static/runtime Evidence plus an explicitly supplied reconstruction manifest. Each obligation should represent one finite claim, not global application equivalence. ## Obligation record An obligation should include: - stable obligation ID and version; - authority Evidence IDs and exact locations; - target artifact/application-graph node; - boundary or behavior family; - observed positive, negative, malformed, cancellation, and teardown cases; - reconstructed owning module and symbol; - parser/schema/domain type where applicable; - fixture IDs and fixture authority; - verifier command/claim ID and latest result Evidence; - allowed nondeterminism/partial-order specification; - dependencies on other obligations; - status: unowned, characterized, implemented, verified, contradicted, blocked, out-of-scope, or unknown; - residual unknowns, unavailable authority, and required next evidence. ## Coverage generation Candidate obligations may be generated from: - CLI commands/options/errors; - REST/GraphQL/Phoenix/WebSocket/JSON-RPC/MCP endpoints and schemas; - IPC/contextBridge/preload/native-addon boundaries; - persisted paths/formats/migrations; - process roles, signals, children, and cleanup; - routes, operations, UI states, and desktop bridge calls; - native exports and ABI surfaces; - application-version deltas; - runtime capture events and negative outcomes. Generation must be conservative. A static literal establishes a candidate obligation, not runtime reachability. One-sided evidence cannot prove behavioral absence. ## Closure rules - `verified` requires comparable authority and reconstruction evidence for the declared finite claim. - A module existing is not proof it owns the behavior. - A unit test is insufficient when the obligation is process-, packaging-, renderer-, ABI-, or protocol-level. - Missing negative coverage remains open when malformed/error behavior is part of the boundary. - A broad verifier cannot silently satisfy obligations it does not enumerate. - Unknown, blocked, waived, and out-of-scope obligations remain visible and cannot count as verified. - Every completion report must enumerate all obligations and prove zero required open items. ## Outputs - canonical JSON ledger; - summary grouped by application layer and evidence authority; - dependency/ownership graph; - missing-owner and missing-verifier report; - contradiction report; - residual-unknown ledger; - deterministic closure digest; - portable Evidence v2/resource representation. ## Acceptance criteria - [ ] A versioned schema defines obligations, ownership, evidence, fixtures, verifier claims, dependencies, and residuals. - [ ] A generator can derive conservative candidate obligations from JavaScript Application Graph and runtime/process Evidence. - [ ] Users can add reviewed obligations without pretending they were automatically observed. - [ ] Reconstruction manifests bind modules/symbols and fixture/verifier IDs to obligations. - [ ] Closure verification fails on missing owner, parser/type, negative fixture, verifier result, or comparable authority. - [ ] Static-only candidates remain static and cannot be upgraded to observed behavior implicitly. - [ ] Duplicate and ambiguous ownership fails closed. - [ ] Contradictory evidence reopens or fails the affected obligation. - [ ] Results are deterministic, pageable, Evidence v2-backed, and exportable as MCP resources. - [ ] CLI and MCP expose identical structured summaries and typed per-obligation diagnostics. - [ ] Fixtures demonstrate that green unit tests cannot close an unexercised packaged-process obligation. - [ ] Documentation gives complete examples for CLI, protocol, Electron, persistence, and native ABI reconstruction. ## Relationship to existing work - Builds on JavaScript Application Graph, JavaScript runtime semantic tracing in #404, and static/runtime reconciliation. - Consumes Process Capture v4 and comparison Evidence. - Complements `verify_reconstruction`; it supplies the finite specification and proves specification coverage rather than claiming global equivalence. - Portable output should align with #336. ## Non-goals - Automatically claiming a whole application has been cloned. - Inventing obligations for unavailable private server internals. - Treating source-file or test counts as behavioral coverage. - Allowing waivers to disappear from completion reports.
bsakaguchi 2026-10-15 18:22:58 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
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#249
No description provided.