[knqiufan]

Which issue or RFC does this PR close?

Refs #1932 and draft implementation #1956. This is a design proposal; both remain open.

Rationale for this change

Image capture needs durable original bytes, asynchronous interpretation and traceable evidence for Memory. The proposal fits those responsibilities into the existing Source, Artifact and Supervisor contracts. Shared media storage lets later audio/video handlers reuse asset identity, request recovery and capacity accounting without creating a separate table set for every modality.

Delayed interpretation also publishes a new Source entry for older evidence. Reconciliation needs comparable, statement-specific ordering support for both incoming evidence and recalled Memory so completion time cannot turn an old fact into a new one.

What changes are included in this PR?

• Matching English and Chinese RFCs, with code references pinned to master 7f38426e and a responsibility comparison against the experimental implementation.
• Original-image Sources, an image-analysis Artifact family and deterministic interpretation-publication Sources for Source-driven Atomic Memory. Existing revisions, lineage, authorization, inspection and Supervisor scheduling are reused.
• Three proposed shared media tables: pc_media_assets, pc_media_processing_requests and pc_media_capacity. The RFC defines common identity/lifecycle/accounting fields, bounded versioned handler data, typed readback and the boundaries for reusing existing storage.
• A stable processing_kind in request identity and active-request uniqueness. Model/profile changes cannot bypass same-purpose exclusion; handlers keep their own validation, Source Definitions, Artifact Families and execution budgets.
• An audio-transcription walkthrough to check reuse, with separate consent, model, resource and time-span qualification required before audio support. Initial delivery remains static PNG/JPEG on qualified file-backed SQLite deployments.
• An explicit two-table transactional-aggregation alternative and a recommended shared capacity ledger. Implementation qualification must compare admission work, lock contention, recovery cost and correctness; neither the ledger nor SQLite BLOB storage is claimed to have measured superiority or suitability for large recordings.
• Shared Atomic Memory ordering support preserved with exact revisions, including bounded resolution and unknown-basis handling for historical/manual Memories. Acceptance covers delayed interpretation, mixed-age statements, reparse, restoration and invalid anchors.
• Five operations for the image workflow, including common media asset/request reads; default-off configuration, qualified Codex capture, standard setup/service lifecycle, migration and host/model/recovery acceptance. Managed local-model provisioning remains future work.

Are there any user-facing changes?

Documentation only. This PR proposes future behavior and makes no runtime, API, database schema or dependency changes. Shared media storage and Memory ordering extensions are implementation requirements, not existing runtime capabilities. Audio/video ingestion is outside the initial release. #1956 remains a draft prototype pending RFC acceptance and implementation alignment.

How was this change tested?

• uv sync --locked and pnpm --dir website install --frozen-lockfile.
• pnpm --dir website lint.
• CI=true pnpm --dir website build: 13 website tests passed; link checks, content generation and production build passed; static export verification confirmed 920 public pages and their internal links.
• SKIP=ty-check uv run prek run -a: all other hooks passed. The native Windows type-check hook was excluded because unchanged code has existing POSIX-only API diagnostics; uv run --no-sync ty check --python-platform linux passed separately. No CI workflow was changed.
• git diff --check; strict UTF-8 without BOM; 14 relative links and 22 pinned source targets verified; bilingual code identifiers and design rules checked for consistency.

These checks validate the documents. Media behavior, the capacity alternatives and actual host/model support require implementation and subsequent qualification.

AI usage statement

OpenAI Codex assisted with source inspection, design comparison, bilingual drafting and documentation checks. The author is responsible for the proposal.