# Source and realization contract v1 (explicit launch opt-in)

Only active when `launch.json.productionQuality` is `source-and-realization-v1`. Keep all ordinary prepare/work/complete gates. No authoring-mode default changes.

## Business and content

At business, enumerate important captured facts and individual services in `onboarding/content-requirements.json`: `{version:1,sourceHash,operatorHash,items:[{id,disposition:"required",factIds:["supported-business-fact-id"],equivalents:["faithful display wording"],equivalenceReason:"why equivalent"}]}`. Hashes use artifacts.fingerprint(root, CONTENT_SOURCE) and contentOperatorHash(root) from production-quality.ts. Every approved fact needs a disposition; multiple atomic services can share a group but each must have its own entry. Enumerate source requirements before compressing the offer. Compare the source with the ledger during business-review.

Keep independently important fields atomic, including a person's name, phone and street address. A compound business fact can support several required ledger entries with the same fact ID, so faithful grouped fields can change order or occupy separate lines without requiring the original sentence. Each field still needs its own coverage match. `equivalents` are alternatives for one item, not a list of different fields that may substitute for each other. Record the actual faithful wording; never replace a complete contact requirement with a name-only alias. If an accepted compound requirement needs this decomposition, reopen business through the supported factual revision rather than forcing pages to copy the harvested sentence.

Optional immutable operator input (also accepted in the pinned launch.json `contentRequirements` field) `agent/content-requirements.json`: `{version:1,requirements:[{id,claim,source:"onboarding/raw/...",excerpt:"captured source excerpt",equivalents:["approved faithful alternative"],allowExclusion:false}]}`. Include every supplied ID in the business ledger and its supported business fact; never delete one to pass a gate. Operator aliases take priority over agent aliases. For a legitimate outdated/excluded source item use `disposition:"excluded",factIds:[...],exclusion:{reason:"specific justification",evidence:"specific source/operator evidence"}`. Operator-required items cannot be excluded without permission recorded in the input. This ledger requires source review; it does not claim automatic semantic enumeration of every harvested sentence.

Copy expansion checks each required item's wording AND fact IDs in an individual copy section. Faithful paraphrases are accepted through recorded alternatives; generic category labels do not replace an individual service. The final browser tool saves visible text per route/width. At content-review compute `coverageAudit(root)` from production-quality.ts and save its exact result to `agent/reviews/content-coverage.json`. The evaluator recomputes it, rejects omissions and stale evidence. An unchanged route list cannot establish coverage. Fix copy/page omissions through the normal owner; justified changes to requirements reopen business.

## Media ownership

Inspect all used customer assets during media. Each needs actual sha256, structured `inspection:{assetHash,description,evidence:[existing-paths],...}`, dimensions and supported identity. Use actual viewed pixels; never invent inspection metadata. Preserve these accepted rows at asset-production. If an older audit lacks inspection metadata, use the supported media revision operation with `kind:"inspection"` to reopen media and dependents BEFORE changing it. Never edit STATE or restore old receipts to recover.

## Direction through rendering

Browser reports and their screenshots belong to the scheduled browser tool nodes. During representative/pages authoring, build into the absolute SITE/dist path and inspect the live preview. If manual diagnostic captures are needed, keep them in a clearly scoped temporary directory outside the protected site tree; they do not replace the runner's evidence. Complete the authoring preparation so the runner can execute its browser node, then inspect its current screenshots at the critic stage. Do not run verify-browser early or create agent/reviews/browser.json, agent/reviews/representative-browser.json or their screenshot directories during an authoring preparation.

At direction add `realizationContract:{version:1,axes:[{axis,intention,observable,decisionIds:[existing-decision-id]}]}` for all nine axes: opening, navigation, typography, imagery, density, proof, interior, mobile, actions. Describe concrete relationships and customer constraints. Specify what type does, how imagery relates to facts, proportions/pacing, how evidence/work can be explored, and important action behavior. An appropriate image-free solution is valid. Do not force a palette, page skeleton or novelty.

At storyboard add `realizationMap:[{axis,routes:["/",...],implementation:"specific sections/global relationships carrying this intent"}]` for all axes. Carry these accepted decisions into representative and expanded pages. Authors may record justified deviations at those stages in `onboarding/direction-deviations.json`: `{version:1,deviations:[{id,axis,reason,preservedConstraints}]}`. Explain actual tradeoffs rather than silently erasing the direction.

At representative-review and visual-review, inspect the CURRENT rendered screenshots. Add `directionFidelity:{subjectHash,observations:[{axis,width:375|1080,screenshot:"current browser PNG path",sha256:"raw image hash",observed:"concrete pixels/geometry/content",relationship:"how these implement the accepted intent",verdict:"survived"|"justified-deviation",deviationId:"when needed"}]}` to the ordinary review. Cover all axes at both widths, including a substantive interior. subjectHash uses fingerprint of direction.json, storyboard.json, direction-deviations.json and the relevant browser report. A screenshot path alone is insufficient; record what it shows. A failed relationship needs ordinary findings and repair, not a fabricated pass. Byte checks bind evidence; they do not prove design quality or human preference. At expansion and final review compare the actual relationships against the accepted direction again.

## Active-agent quality completion

At representative-quality, when you are the active visual reviewer, actually open the current capability probe and every current representative PNG with an approved image tool. Record the real successful calls in a JSON array outside the protected site tree: `[{"tool":"view_image","path":"actual image path","success":true,"hash":"actual raw PNG SHA256"}]`. Each entry must describe an image call you actually performed; computing hashes or listing files is not inspection. Use the observed probe color, never read its answer from implementation metadata. Read current capture paths/hashes through the supported design-quality exports if needed; those lists do not substitute for opening pixels.

Pass the absolute event-file path to the ordinary completion command: `vitris-go --site ABSOLUTE_SITE --complete --preparation CURRENT_ID --visual-tool-events ABSOLUTE_EVENTS_JSON --no-preview-server`. The completion runner records the active-agent-visual receipt bound to the preparation, probe and captures. Do not hand-write the receipt or claim an external adapter invocation. The events are self-recorded observations, not an exported host transcript, independently verified tool-call log or human review. Never invent successful events, dataBlobIds, old session identifiers or usage. Missing events/current hashes/preparation bindings and unavailable pixels still fail; configured external adapters retain their supported provenance path. A quality failure consumes its preparation; resume for a new one through the ordinary owner and budget.