# Repeated XML Artifact Identity Fix

## Claim

The Web upload failure `PROCESSING_SOURCE_INVALID: processing source object is unavailable` was caused by database content deduplication reusing an older run's artifact row. Migration 011 fixes that failure. A post-fix real upload now reaches SuperAgent, but the wider E2E remains blocked because the successful remote run did not call the direct-result MCP tool.

## Runtime Evidence

- Four repeated submissions created processing runs 17 through 20 between 20:29 and 20:32.
- Each run had a queued attempt and an issued, unconsumed direct-MCP grant, but no remote run identifier and no result submission.
- All four new runs pointed to the same `opera_xml` artifact row and therefore to the committed object key belonging to run 16.
- `OssProcessingMessageBuilder` correctly requires the current `job_id` to be a path segment in the source object key, so it rejected those cross-run references before Open Agent dispatch.
- The browser rendered the safe error text but incorrectly described the task as not created even though the database registration and grant already existed. That display issue remains separate from the identity fix.

## Root Cause

Migration 008 imposed `UNIQUE (artifact_kind, sha256)`, and `PostgresIngestionRepository._ensure_artifact()` looked up artifacts only by those two content fields. Reusing the same XML bytes in a new run therefore reused the old row and old job-scoped OSS key. This contradicted the intended rule that equal content may be processed in independent run/attempt identities.

## Change

- Migration 011 replaces the content uniqueness constraint with a non-unique lookup index. The existing storage-identity unique index remains authoritative.
- `_ensure_artifact()` now finds an artifact by provider, bucket alias, object key and null object version, then verifies all immutable metadata before reuse.
- Three repository regressions cover new-object insertion for equal content, exact storage-identity reuse and metadata conflict rejection.
- Two migration regressions cover the forward shape and the guarded rollback refusal after repeated content exists.

## Verification

- 57 targeted ingestion, direct-ingestion, processing and Web tests passed.
- The complete suite passed 269 tests with 2 expected environment skips.
- An up/down transaction rehearsal passed against `booking_test`.
- Migration 011 was formally applied; artifact row count remained 12 and the expected non-unique lookup index replaced the content uniqueness constraint.
- The controlled 8765 service was restarted and reported all database, processing and writeback health gates as ready.
- The user-authorized `0721.XML` was submitted through the real ARR session/CSRF upload endpoint as job `arrjob-51284ae50150454f9c085b461be7f0d8`. Its new source key contains that job identity, and two independent `opera_xml` artifact rows now exist for the equal content.
- Remote run `3e17e1d3-3b06-4e9b-b008-e231770618b2` started successfully and the Open Agent API reports `success` with no platform error. It resolved the intended Profile and current enterprise MCP configuration version 53.
- After the remote terminal state and an additional propagation window, the grant remained unconsumed, no result submission or Finance version existed, and the grant later expired. Therefore this run proves upload/dispatch but not MCP/Finance completion.
- The authenticated Ops page could be opened, but structured log reads timed out twice. Exact Agent-step diagnosis requires the exported full run log; no further upload should be attempted until that log is reviewed.

## Staleness Trigger

Reverify after changes to artifact identity schema, `PostgresIngestionRepository._ensure_artifact()`, object-key policy, or the active 8765 runtime.
