No SourceAssetCorpus: crawled source imagery has no rights disposition, dedupe, or visual-role model, so authentic client photography cannot be preferred over generation

[cryptoxdog]

Summary

There is no SourceAssetCorpus or equivalent. SourceSiteManifest records crawled images, but carries no rights, disposition, provenance, perceptual hash, visual role, or reuse-authorization concept. Nothing can decide whether a source image is legitimately reusable in generated output.

Observed at 70f3f9a4.

Current state

• SourceSiteIngestionStage (src/stages/SourceSiteIngestionStage.ts) crawls and downloads images with sha256 + dimensions, and explicitly "interprets nothing".
• ImageAssetPlanner (src/services/images/ImageAssetPlanner.ts) scores candidates by aspect ratio, placement, and alt-keyword match. It has heuristics for hero/logo/brand-mark detection but no rights model — nothing distinguishes "client owns this photo" from "this image merely appeared on the domain".
• Source ingestion is additionally gated on assets.sourceSite.enabled === true, and no committed spec sets it (grep sourceSite over all specs → 0 hits), so the stage is currently a no-op repo-wide.

Why this matters

Without a disposition model the planner cannot prefer authentic client photography over generated imagery, because it cannot establish that reuse is authorized. The failure mode is silently replacing real project/gallery photography with generated stock-like imagery — losing exactly the visual proof that makes the site credible.

The capability must be independent of Copy Mode. Harvesting and authorized reuse of client assets is not layout reconstruction, and must not be coupled to a COPY intent or reintroduce one.

Expected

A SourceAssetCorpus primitive that inventories real source-site visual assets, capturing where available: source URL, source page(s), DOM role, content hash, perceptual hash, byte length, width/height, aspect ratio, MIME type, alt text, nearby semantic context, likely visual role, quality assessment, authenticity/relevance assessment, reuse disposition, provenance evidence, and rejection reason when not reused.

Visual role vocabulary should cover at least: hero, project_proof, gallery, service, team, trust, process, material, background, logo, badge, decorative, unknown.

Deduplicate identical and near-identical assets — different renditions/sizes of one underlying image must not inflate the canonical corpus.

Rights model — fail closed

Disposition	Output eligibility
SOURCE_CLIENT_OWNED	reusable
SOURCE_LICENSED_REUSE	reusable within recorded constraints
SOURCE_REFERENCE_ONLY	analysis only
DONOR_REFERENCE_ONLY	analysis only
UNKNOWN	analysis only — never output

Never infer client ownership from the fact that an image appears on the source domain. The run/input contract must be able to state source reuse authorization explicitly. Attempting to emit an UNKNOWN asset should raise SOURCE_ASSET_RIGHTS_UNKNOWN.

Donor/competitor assets default to DONOR_REFERENCE_ONLY — crawlable, screenshottable, analyzable as visual/pattern evidence, but never candidate output assets without separate explicit authority. No competitor asset cloning or redistribution.

Resolution precedence

1. approved high-quality SOURCE_CLIENT_OWNED
2. approved SOURCE_LICENSED_REUSE
3. generated original
4. no asset, only where the blueprint explicitly permits it

Generated imagery fills gaps; it must not automatically displace authentic, high-quality client photography. Every slot should emit a machine-readable resolution record: slot id, blueprint requirement ref, selected source type, selected asset ref, rejected candidates with reasons, transformation/crop, final provenance.

Operator authorization on record

For Safe Haven validation the operator has authorized:

source_assets:
  harvest: true
  reuse_policy: client_owned_authorized

This applies to Safe Haven source/client imagery only. It does not authorize donor/competitor imagery reuse. Note that these keys are currently inert — validateDomainSpec has no source_assets field, so they would be silently dropped until spec-schema work lands (see the intent-threading issue). They should be introduced in the same change that makes them load-bearing, not before.