Swamp reconciliation

Type: agentic-system-analyses/types/agentic-system-reconciliation-report.md

Reconciliation

Boundary and evidence

The four reports share the revision and source scope in boundary and its Source register. Their implementation findings concern SRC-1; none supplies observed operation or causal experiments. External-agent inference, conversation restoration, model weights and hosted-service internals remain outside the inspected implementation. This reconciliation uses the pinned members only; it adds no source reads, judgments of individual support, public synthesis or verification verdict.

Duplicate supersession and retained containers

Amendment: EPI-RTE-issue-feedback is superseded by MEM-RTE-plan-iteration. Both identify the same caller-supplied feedback/revised-plan import through iterate in SRC-1, extensions/models/issue_lifecycle.ts: read current plan and feedback, persist feedback and the next plan, reset phase, and attempt lifecycle posting. Both also discuss the subsequent review display and instructed revision loop. Their different labels and epistemic functions do not establish another route. The memory record retains the latest-per-name enumeration finding; the epistemic record retains its own import, retention and doctrine-only integration assessments. Supersession connects the referent without replacing either report's field values or upgrading incorporation, acceptance or operation.

EPI-OBJ-plan is a container for the plan and feedback separately described by MEM-OBJ-plan-main and MEM-OBJ-feedback-main. The same resource names and SRC-1 extension passages establish the overlap. Neither individual memory object is identical to the combined epistemic object. The container explicitly distinguishes prose from version/time fields and treats caller revision as import, not evidence of semantic incorporation. Its findings do not become wrong merely because the parts are separately addressable, so no split supersession is made. The plan's lossy review display, feedback's uncertain authorship and each part's retention policy remain local memory findings.

EPI-OBJ-adversarial-review identifies the adversarial-review resource within MEM-OBJ-review-findings, which also covers code-conformance findings. Both cite SRC-1, extensions/models/issue_lifecycle.ts, but the latter is not solely the adversarial resource. Exact identity and supersession are therefore ruled out. The broader record distinguishes the check targets and admits less inspection of conformance transformations; it remains a valid container rather than a substitute for the adversarial part.

EPI-RTE-issue-clearance is the specific adversarial-clearance callback, while MEM-RTE-lifecycle-checks spans that callback, PR-link verification, finding resolution and instructed later-session phase reload. They are not identical routes. The callback is already declared separately, and the broader memory account differentiates its consumers and force. No supersession is needed. MEM-BAP-retained-checks denotes the retained-input authority path, not another declaration of either route.

EPI-RTE-activity-summary covers the method-aggregation part of MEM-RTE-activity-summary. Their SRC-1 paths, cutoff/limit selection and counts-before-detail-truncation agree, but epistemic explicitly leaves workflow/data branches unassessed. This is narrower coverage within a valid broader account, not exact record identity; no supersession is made. Its later-read-back field excludes persistence of the computed display, whereas memory describes the summary invocation reading retained source history. These are different edges of the same chain, not incompatible persistence findings.

Distinct records and complementary routes

MEM-OBJ-data-content and MEM-RTE-resource-storage describe the content substrate and writer/reader capability underlying RT-RTE-behavior-run. They are neither the execution route nor RT-OBJ-workflow-run. Method-argument rejection and resource-schema warnings apply at different controls and do not conflict. The memory annotations retain the runtime task brief and workflow-run identities rather than duplicating them.

EPI-RTE-preflight-check explicitly declares itself part of RT-RTE-behavior-run; EPI-RTE-issue-clearance explicitly declares itself part of RT-RTE-issue-admission. Callback selection, the specific clearance predicate and the eventual approval phase mutation are different operations. None is identical to RT-RTE-gate-resume, whose target is a workflow waiting gate rather than an issue plan. The configured local preflight path, caller skip controls, remote differences and natural-language consent policy must remain separate.

MEM-OBJ-method-report and MEM-RTE-report-retrieval cover the method-summary representations, report persistence and requested retrieval. EPI-OBJ-verification-summary and EPI-RTE-report-summary concern the different built-in verification summary and its persistence wrapper. Shared report infrastructure in SRC-1, src/domain/reports/report_execution_service.ts, does not make the built-in products or complete routes identical. No supersession follows. Both accounts preserve the empty-Markdown case that leaves the previous meaningful artifact latest.

EPI-OBJ-attestation, EPI-RTE-attestation-build and EPI-RTE-attestation-ci are a multi-run projection and downstream CI admission, not the one-run verification summary, original scheduler state or reviewer prose. Likewise EPI-OBJ-skill-evals and EPI-RTE-skill-evals have fixture/tool-choice and external-score targets distinct from RT-RTE-review-verdict. Identity is ruled out across these products and checks; their different criteria must not be collapsed into a universal accuracy gate.

MEM-OBJ-command-audit and MEM-RTE-audit-timeline are selected raw command capture and requested display, not a task brief, workflow run, derived policy or activity summary. The epistemic coverage statement about no hooks in .claude/settings.json is local to that file and explicitly not a system-wide absence. It does not disagree with memory's direct inspection of managed hook templates in SRC-1, src/domain/repo/repo_service.ts.

MEM-RTE-data-query supplies requested retained fields rather than executing the producing behavior. MEM-RTE-data-cleanup withdraws availability by mechanical policy rather than performing scheduler recovery, semantic rejection or model-context compaction. These identities are distinct from the runtime execution and continuation routes. No other cross-member duplicate is established by the supplied declarations; workflow declares none.

Integration-issue dispositions and convergence

The memory integration request concerning RT-RTE-issue-admission is met by connecting MEM-RTE-lifecycle-checks, MEM-BAP-retained-checks and EPI-RTE-issue-clearance. Runtime assesses empty approval arguments and unauthenticated conversational consent; the specialists add the separate computational clearance. The epistemic mismatch labels identify an omission to supplement, not a contrary assertion that runtime declared clearance absent. The combined account must carry both positions: selected checks can veto approval based on retained fields, while those fields do not authenticate human consent or establish plan correctness. No correction answers or declined objections were supplied to this attempt, and no analyst finding is silently rewritten here.

The feedback-history issue is local to MEM-RTE-plan-iteration: the extension's all-prior-feedback label is contrasted with latest-per-name enumeration in SRC-1, src/infrastructure/persistence/unified_data_repository.ts. EPI-RTE-issue-feedback already limits prior enumeration by repository behavior and asserts no complete historical guarantee. The boundary's initial description that iteration enumerates prior feedback does not assert enumeration of every version. There is no cross-report disagreement requiring a stronger history claim or a universal deployed-failure finding.

The incomplete-display issue remains attached to MEM-OBJ-plan-main, MEM-OBJ-method-report and their read-back routes. Epistemic likewise says plan review does not display every stored field. Retention, display and later interpretation are separate; no report establishes full rationale delivery merely from an artifact label.

The workflow account, its annotation on RT-RTE-review-verdict, and the epistemic ledger converge on the same review route. Workflow adds guard polarity, diff-pointer handoff, pipeline failure, best-effort cleanup and caller-owned repair. Runtime and epistemic agree that provider-error detection precedes the first matching line-initial verdict marker, which need not be the first response line. Epistemic's concrete input contrasts are code deductions, not new observed runs. These additions neither create duplicate route identities nor establish semantic review accuracy or universal merge admission.

Memory's remaining integration limits—uncertain feedback authorship and criticism, uninspected cache invalidation, authorization, report alternatives, deletion convergence, acquisition and evaluation/adoption consumers—remain limits. Epistemic inspects some additional verification/attestation paths, but does not retrospectively make memory's direct inspection exhaustive. Workflow deliberately ends at review delivery, while epistemic separately examines downstream attestation. Different inspected coverage is not a conflict.

No unresolved cross-report disagreement is established by these pinned versions. Their independent positive findings about retention, selective read-back, configured checks and review delivery coexist with their separate limits on observed compliance, beneficial learning, autonomous adaptation and exercised self-improvement. Uninspected paths and external responsibilities prevent broader conclusions; they are not evidenced absences.