@dailephd/my-frontend-observer 0.8.1 → 0.9.0

package/docs/ARCHITECTURE.md

@@ -21,17 +21,20 @@ the workflow result remain in memory/presentation.
 ## Current package architecture
 
 The current repository is one published TypeScript ESM package
-(`@dailephd/my-frontend-observer@0.8.1`). The CLI remains
+(`@dailephd/my-frontend-observer@0.9.0`). The CLI remains
 `my-frontend-observer`; the npm scope does not rename the product or artifact
 identities.
 
 - `src/cli.ts` is the real, thin public CLI parsing/dispatch/presentation
   boundary for the current command surface (`observe`, `compare`,
   `approve-baseline`, `save-change-contract`, `evaluate-contract`,
-  `import-reference`, `approve-reference`, `evaluate-reference-fidelity`);
-  argument parsing and output formatting only, per command - the commands do
-  not share domain semantics in the CLI. v0.6 added no new CLI command; v0.7
-  added the three external-reference commands.
+  `import-reference`, `approve-reference`, `evaluate-reference-fidelity`,
+  `view`, `init`, `capture`, `check`); argument parsing and output formatting
+  only, per command - domain semantics remain owned by application/domain
+  services rather than the CLI. v0.6 added no new CLI command; v0.7 added the
+  three external-reference commands; v0.8 added `view`; v0.8.1 added `init`,
+  `capture`, and `check` and made `view` project-aware while preserving its
+  standalone `--root` behavior.
 - `src/index.ts` is the library entry point re-exporting the observer-owned
   contracts/functions from every layer below, including the v0.6 bounded-agent-
   context projection and runtime/static correlation surface, and the v0.7
@@ -374,8 +377,10 @@ actual architecture, and `docs/CURRENT_STATE.md` for release state. It
 extends the existing v0.1-v0.6 evidence architecture rather than becoming a
 UI-only feature or a parallel visual-comparison stack. v0.8 (interactive
 viewer) is released as package version `0.8.0`. v0.9 (structured visual
-annotation) and v0.10 (full graphical human-LLM workflow) remain future and
-unimplemented; the constraints below apply to that still-future work.
+annotation) is released as package version `0.9.0` - see "v0.9 visual
+annotation architecture" below. v0.10 (full graphical human-LLM
+workflow) remains future and unimplemented. The constraints below applied to
+v0.9 and still apply to v0.10.
 
 The evidence domains remain distinct:
 
@@ -442,8 +447,9 @@ described in "v0.7 Prompt 1" through "v0.7 Prompt 8" below: explicit
 identity/provenance, applicability/compatibility, region-to-target bindings,
 requested/expected-dependent/protected/preserved reuse, and the non-mutating
 Chromium/correlation boundaries all remain as constrained here. v0.8 (see
-"v0.8 Batch 1" through "v0.8 Batch 8" below) applied them unchanged; they
-continue to apply unchanged to the still-future v0.9-v0.10 work.
+"v0.8 Batch 1" through "v0.8 Batch 8" below) applied them unchanged, and so
+does the implemented v0.9 annotation layer. They continue to apply unchanged
+to the still-future v0.10 work.
 
 The exact public artifact names, schema versions, persistence layout, supported
 image formats, coordinate model, requirement/tolerance primitives, and fidelity
@@ -1076,6 +1082,86 @@ record.
   re-running the exact `grep -rn` audit from earlier batches - unchanged
   findings, no duplicate evidence engine exists.
 
+## v0.9 visual annotation architecture (released in 0.9.0)
+
+v0.9 is released as package version `0.9.0`. It adds one new
+evidence family and a narrow local authoring path to the existing viewer. It
+adds no new evaluator, no second contract or reference model, and no new
+PASS/FAIL semantics.
+
+**Evidence ownership**:
+
+- `src/domain/visualAnnotation.ts` owns `VisualAnnotationArtifact` (artifact
+  kind `my-frontend-observer/visual-annotation`, schema `1.0.0`): the source
+  union, structured marks, explicit associations, candidate/confirmed
+  interpretation, validation, and the pure overlay SVG renderer.
+- `src/domain/visualAnnotationIdentity.ts` owns deterministic request identity
+  and fresh instance identity.
+- `src/artifacts/visualAnnotationArtifactWriter.ts` and
+  `visualAnnotationArtifactReader.ts` own atomic persistence (temporary
+  `.tmp-<id>` directory, then rename) and canonical reading, including the
+  derived `annotation-overlay.svg` and its digest.
+- `src/application/visualAnnotationPersistenceService.ts` owns saving one
+  annotation or one superseding revision.
+
+**Coordinate domains**: runtime annotations use the observation's runtime CSS
+pixel space. Reference annotations use the reference image's own pixel space
+(for an approved reference, the owning imported image). The two domains are
+never mixed. Zoomed or panned drawing is mapped back through the SVG's own
+transform (`viewer/src/svg/sourceCoordinates.ts`).
+
+**Viewer discovery and media** (`src/viewerServer/evidence/`): the index
+classifies `visual-annotation` evidence and skips writer `.tmp-*`
+directories. `annotationView.ts` resolves an annotation's exact canonical
+source and reports `unavailable` instead of guessing a replacement. The media
+resolver serves the `annotation-overlay` role only after re-rendering the SVG
+from the artifact and verifying it, with a script-blocking sandbox policy.
+
+**Project-aware authoring security**: `src/viewerServer/authoringSecurity.ts`
+owns the in-memory 32-byte session capability and the Host, Origin, token,
+content-type, and content-encoding checks. `httpServer.ts` owns the shared
+bounded JSON gate and routes exactly three `POST` responsibilities.
+`view --root` never creates an authoring session, so the standalone
+arbitrary-root viewer stays read-only.
+
+1. `POST /api/annotations` (`src/viewerServer/annotationAuthoring.ts`) saves
+   a new annotation or a revision through the canonical persistence service,
+   with stale-parent conflict detection. This module also owns the single
+   per-session write queue used by all three routes.
+2. `POST /api/annotations/:handle/promote-contract`
+   (`src/viewerServer/annotationContractPromotion.ts`) calls
+   `src/application/visualAnnotationContractPromotionService.ts`. Selected
+   confirmed runtime intent becomes one canonical `PerChangeContract` through
+   the existing contract persistence service. Optional activation goes only
+   through `activateProjectChangeContract` in
+   `src/application/projectWorkflowService.ts`.
+3. `POST /api/annotations/:handle/materialize-reference`
+   (`src/viewerServer/annotationReferenceMaterialization.ts`) calls
+   `src/application/visualAnnotationReferenceMaterializationService.ts`.
+   Selected confirmed reference intent becomes a new imported
+   `ExternalReferenceArtifact` through the existing `importExternalReference`,
+   superseding the source. The image bytes come only from the safe media
+   resolver.
+
+Output locations come from `src/projectWorkflow/projectPaths.ts`
+(`annotations`, `contracts`, and `references` under
+`.frontend-observer/evidence`). The browser never supplies a path.
+
+**Viewer UI** (`viewer/src/`): `annotation/` holds pure presentation models
+(`annotationGeometry.ts`, `runtimeIntent.ts`, `referenceIntent.ts`,
+`confirmation.ts`). `components/AnnotationLayer.tsx`,
+`AnnotationToolbar.tsx`, `RuntimeAnnotationPanel.tsx`,
+`ReferenceAnnotationPanel.tsx`, `CandidateRegionPreviewLayer.tsx`, and
+`AnnotationPanelSections.tsx` render marks, tools, intent, promotion, and
+materialization. Hooks under `hooks/` hold draft, saved-list, session,
+pointer, promotion, and materialization state. The authoring token lives only
+in React memory.
+
+**Existing evaluators remain authoritative**: the canonical contract
+evaluator, reference relationship derivation, requirement adequacy, reference
+fidelity, and project `check` are unchanged. Annotation evidence feeds them
+only through promoted contracts and materialized references.
+
 ## Retained v0.1 architecture constraints
 
 v0.1 planning preserved these approved boundaries without treating module
@@ -1241,18 +1327,19 @@ itself, not a new parallel context system, gains one new optional input (an
 already-computed Prompt 6 fidelity evaluation): fidelity-relevant runtime
 targets fold into the exact same required/permitted-target-allocation,
 evidence-tiering, omission/truncation, and adequacy machinery v0.5 contract
-clauses already compete in, and a new `fidelity?` field on
-`BoundedAgentContextArtifact` (mirroring `correlations?`'s own additive,
-non-version-bumping precedent from v0.6 Batch 3) carries a bounded,
-priority-ordered selection of Prompt 6's non-passing requirement results
-plus passing protected/preserved context. No second bounded-context
-architecture, no recomputation of Prompt 2-6/v0.4/v0.5 logic, and no change
-to v0.6's own runtime/static correlation (`deriveRuntimeStaticCorrelations`/
-`attachRuntimeStaticCorrelations` are untouched and reused exactly as
-before) - a caller joins fidelity, target, and correlation evidence by the
-one stable v0.2 runtime target id all three already share. Every new field
-is optional and additive; a pre-Prompt-7 caller supplying no fidelity
-evidence receives byte-identical output, including logical identity.
+clauses already compete in, and a new `fidelity?:
+BoundedReferenceFidelityProjection` field on `BoundedAgentContextArtifact`
+(mirroring `correlations?`'s own additive, non-version-bumping precedent
+from v0.6 Batch 3) carries a bounded, priority-ordered selection of Prompt
+6's non-passing requirement results plus passing protected/preserved
+context. No second bounded-context architecture, no recomputation of Prompt
+2-6/v0.4/v0.5 logic, and no change to v0.6's own runtime/static correlation
+(`deriveRuntimeStaticCorrelations`/`attachRuntimeStaticCorrelations` are
+untouched and reused exactly as before) - a caller joins fidelity, target,
+and correlation evidence by the one stable v0.2 runtime target id all three
+already share. Every new field is optional and additive; a pre-Prompt-7
+caller supplying no fidelity evidence receives byte-identical output,
+including logical identity.
 
 v0.7 Prompt 8 adds the first complete, controlled end-to-end external-
 reference correction workflow (`domain/referenceCorrectionWorkflow.ts`,

package/docs/CI_CD.md

@@ -1,6 +1,6 @@
 # CI/CD
 
-CI interprets `check` as PASS `0`, FAIL `1`, REVIEW_REQUIRED `2`, or BLOCKED `3`. The released package is `@dailephd/my-frontend-observer@0.8.1`; its CLI remains `my-frontend-observer`. Packed readiness installs one exact tarball and runs `runPackedViewerSmoke.mjs` as the single project/viewer smoke owner for `init`, `capture`, bounded `check --json` REVIEW_REQUIRED and unchanged-contract FAIL-to-PASS, alias-aware project `view`, and viewer security. `runPackedObservationSmoke.mjs` remains the lower-level legacy observation smoke.
+CI interprets `check` as PASS `0`, FAIL `1`, REVIEW_REQUIRED `2`, or BLOCKED `3`. The released package is `@dailephd/my-frontend-observer@0.9.0`; its CLI remains `my-frontend-observer`. Packed readiness installs one exact tarball and runs `runPackedViewerSmoke.mjs` as the single project/viewer smoke owner for `init`, `capture`, bounded `check --json` REVIEW_REQUIRED and unchanged-contract FAIL-to-PASS, alias-aware project `view`, and viewer security. `runPackedObservationSmoke.mjs` remains the lower-level legacy observation smoke.
 
 A GitHub Actions pre-release readiness workflow exists at
 `.github/workflows/pre-release-readiness.yml` (triggered manually via
@@ -248,3 +248,59 @@ evidence-root escape in the viewer's media route) both passed before this
 release - see
 `docs/reports/v0.8-prerelease-readiness-cross-platform-security-code-rot.md`
 for the complete readiness report.
+
+## v0.9 packaging implications (released in 0.9.0; final cross-platform readiness passed)
+
+v0.9 visual annotation is released as `@dailephd/my-frontend-observer@0.9.0`.
+Final exact-candidate readiness passed on Windows, Linux and macOS - see
+`docs/reports/v0.9-final-pre-release-readiness.md`.
+`.github/workflows/pre-release-readiness.yml` keeps the same exact-candidate
+structure:
+
+1. The `candidate` job runs once on Linux with Node 24. It runs every local
+   validation command, builds the package, creates one tarball with
+   `npm pack --json`, freezes its SHA-256, and uploads both.
+2. The `matrix-smoke` job runs on `windows-latest`, `ubuntu-latest`, and
+   `macos-latest` with Node 24. Each lane downloads that same tarball and
+   fails if its SHA-256 differs.
+3. Each lane installs the tarball into a clean consumer and runs three packed
+   smokes in real Chromium:
+   1. `scripts/ci/runPackedObservationSmoke.mjs` (observation and low-level
+      command behavior), writing `smoke-summary.json`;
+   2. `scripts/ci/runPackedViewerSmoke.mjs` (project workflow and
+      project-aware viewer inspection), writing `viewer-smoke-summary.json`;
+   3. `scripts/ci/runPackedV09AnnotationSmoke.mjs` (v0.9 annotation), writing
+      `v09-annotation-smoke-summary.json`.
+4. All three summaries are uploaded as the `smoke-summary-<os>` artifact.
+
+The v0.9 annotation smoke uses only the installed package. It checks that the
+compiled v0.9 owners and the built viewer are in the tarball, that the bare
+package specifier and Playwright resolve inside the consumer's own
+`node_modules`, and that the public v0.9 exports resolve. It then runs
+`init`, `capture baseline`, and `check baseline --json`, and starts the
+project-aware `view` (viewer protocol `1.3.0`, authoring enabled). In real
+Chromium it saves and reloads a runtime annotation, promotes confirmed move
+intent into a canonical change contract, imports a reference with the
+installed `import-reference`, annotates it, and materializes a confirmed
+region into a new imported revision. That revision must supersede the source,
+reuse its exact image bytes, and not be approved. Finally it starts a
+standalone `view --root` session and proves it is read-only. The summary never
+contains the authoring token, absolute project paths, or note text.
+
+The standalone read-only proof for v0.9 authoring lives in the v0.9
+annotation smoke. The project-aware inspection and project workflow proof
+lives in the packed viewer smoke.
+
+A separate `tutorial-readiness` job runs on the same three operating systems.
+It builds Observer from the repository source and runs
+`scripts/run-v09-tutorial-readiness.mjs`, which validates and runs the four
+`examples/v09-demo/tutorials/` scenarios through the external tool
+`@dailephd/my-dev-kit-lab@0.4.9`, then reads the evidence each run wrote back
+through the canonical Observer readers. It fails unless every scenario passes
+with empty `cleanupErrors`, the tracked demo source is unchanged, and the
+repository status is unchanged. The demo and the lab are repository release
+support only. Neither is in the npm package or an Observer dependency.
+
+The v0.9 matrix wiring has not yet run in GitHub Actions for this candidate.
+The local Windows run of all three smokes against one exact tarball is
+recorded in `docs/reports/v0.9-batch7-integrated-acceptance.md`.

package/docs/COMMANDS.md

@@ -757,8 +757,33 @@ and exits nonzero.
 
 ## `view`
 
-**Current status: v0.8.1 viewer behavior is released as package
-`@dailephd/my-frontend-observer@0.8.1`.** Starts one
+**v0.9 visual annotation (released in `0.9.0`).**
+There is no separate annotation command. `view` is the annotation entry point:
+
+- `my-frontend-observer view` (inside an initialized project, without
+  `--root`) is the normal project-aware viewer. It enables local annotation
+  authoring for that project. In the browser you can draw on observations and
+  external references, explicitly associate and confirm structured intent,
+  save immutable annotations, promote selected confirmed runtime intent into a
+  change contract, and materialize selected confirmed reference intent into a
+  new imported reference revision. New artifacts are written only under the
+  project's managed evidence root (`.frontend-observer/evidence`). Nothing is
+  approved automatically.
+- `my-frontend-observer view --root <root>` is the advanced standalone form
+  for arbitrary evidence roots. It is always read-only. Saved annotations can
+  be inspected but not edited, and every authoring request is refused.
+
+In a project-aware session the viewer protocol is `1.3.0` and the API adds
+`GET /api/authoring/session`, `GET /api/annotations/<handle>/view`, the
+`annotation-overlay` media role, and exactly three authoring routes:
+`POST /api/annotations`, `POST /api/annotations/<handle>/promote-contract`,
+and `POST /api/annotations/<handle>/materialize-reference`. See
+`docs/SECURITY.md` for the local write boundary and `docs/WORKFLOWS.md` for
+the annotation workflow. The rest of this section describes the inspection
+surface, which is unchanged.
+
+**Current status: viewer behavior is released as package
+`@dailephd/my-frontend-observer@0.9.0`.** Starts one
 loopback-only Node viewer server and serves the same React + TypeScript +
 Vite application to a normal browser or an installed Progressive Web App.
 `--root` is used as a bounded, read-only evidence-discovery root: the server
@@ -925,8 +950,10 @@ Options:
 The server binds only to `127.0.0.1` (never `0.0.0.0`), serves only the
 built viewer application assets plus the bounded, read-only `/api/*`
 endpoints described above, and never exposes the supplied evidence root as a
-generic static directory or arbitrary filesystem path. It accepts no write
-methods and mutates nothing. On success,
+generic static directory or arbitrary filesystem path. With `--root` it
+accepts no write methods and writes nothing. Without `--root`, the only
+writes are the three v0.9 authoring routes above, which create new immutable
+artifacts and never modify existing ones. On success,
 prints the viewer URL and keeps running (serving the viewer) until
 interrupted. On invalid syntax, a missing/non-directory `--root`, an
 invalid `--port`, an invalid `--bindings-file`, an invalid `--context-file`
@@ -934,6 +961,19 @@ invalid `--port`, an invalid `--bindings-file`, an invalid `--context-file`
 normally), or a port already in use, prints structured diagnostics to
 stderr and exits nonzero without starting a server.
 
+## Cross-tool compatibility handoffs
+
+The canonical command-by-command composition map is [my-dev-kit ecosystem workflow section 9.15](https://github.com/dailephd/my-dev-kit/blob/main/docs/ECOSYSTEM_DEVELOPMENT_WORKFLOWS.md#915-command-surface-compatibility-map).
+
+Current supported boundaries:
+
+- my-dev-kit file/symbol evidence can be mapped by a small **programmatic adapter** into the plain caller-supplied static-candidate records accepted by `deriveRuntimeStaticCorrelations(...)` / `attachRuntimeStaticCorrelations(...)`. Raw my-dev-kit search, lookup, slice, or context JSON is not a direct Observer CLI input.
+- A produced Observer `BoundedAgentContextArtifact` can be inspected directly with `view --context-file <file>`. That option accepts only the Observer bounded-context schema, not a my-dev-kit context capsule.
+- Orchestrator has a direct programmatic consumer for the released Observer bounded-agent-context wire contract. Orchestrator does not launch Observer.
+- A selected Lab tutorial screenshot PNG can be passed to `import-reference`, then explicitly approved and bound like any other external image reference. The Lab tutorial manifest and behavioral assertions are not imported.
+- Lab report/gallery commands do not generically consume Observer evidence roots, and Observer commands do not consume Lab security/audit/experiment reports.
+- `check [baseline] --json` is the preferred compact final-candidate runtime result for an external coding-agent or Orchestrator report, but the downstream consumer must preserve `PASS`, `FAIL`, `REVIEW_REQUIRED`, and `BLOCKED` rather than collapse them to process success/failure.
+
 ## Foundation commands
 
 - `npm install` — install dependencies (includes the `playwright` runtime

package/docs/CONTRACTS.md

@@ -490,7 +490,7 @@ blockers; on the canonical worktree, `npm run typecheck`, `npm run lint`,
 `npm test` (627 tests), `npm run test:browser` (120 tests), `npm run
 test:security`, `npm run build`, and `npm run check:docs` all pass.
 
-## v0.7 external visual-reference contract direction (released as `0.7.0`; v0.8 viewer released as `0.8.0`; v0.9-v0.10 still future)
+## v0.7 external visual-reference contract direction (released as `0.7.0`; v0.8 viewer released as `0.8.0`; v0.9 released as `0.9.0`; v0.10 still future)
 
 External visual-reference support is released as package version `0.7.0`
 (see "v0.7 Prompt 1" through "v0.7 Prompt 8" below for the exact contract).
@@ -498,8 +498,9 @@ The exact public type names, artifact kinds, schema versions, persistence
 layout, and command/programmatic entry points were designed during v0.7
 implementation from current repository precedent, following the constraints
 below. v0.8 (released as package version `0.8.0` - see
-`docs/CURRENT_STATE.md`) has preserved them; v0.9-v0.10 remain future and
-must continue to preserve them.
+`docs/CURRENT_STATE.md`) has preserved them. v0.9 (implemented, not yet
+released) preserves them too. v0.10 remains future and must continue to
+preserve them.
 
 **Distinct evidence domain**: an external reference is desired-design evidence,
 not an `ObservationArtifact` and not the "before" side of a v0.4
@@ -569,11 +570,80 @@ The v0.8 viewer, released as package version `0.8.0`, consumes this v0.7
 reference/evaluation contract exactly as required - it creates no UI-only
 reference model (see `docs/ARCHITECTURE.md` "v0.8 Batch 5"/"v0.8 Batch 6"
 and `docs/reports/v0.8-reference-candidate-inspection-batch5.md`). v0.9
-annotations may originate
-from runtime screenshots or external references but must preserve which source
-identity/coordinate system they belong to and feed the same canonical contract
-semantics. v0.10 combines both entry modes into the full correction/approval
-workflow.
+annotations (released in `0.9.0`) originate from runtime
+screenshots or external references, preserve which source identity and
+coordinate system they belong to, and feed the same canonical contract and
+reference semantics - see "v0.9 visual annotation contract" below. v0.10
+combines both entry modes into the full correction/approval workflow.
+
+## v0.9 visual annotation contract (released in 0.9.0)
+
+v0.9 is released as `@dailephd/my-frontend-observer@0.9.0`.
+
+**Artifact**: `VisualAnnotationArtifact`, artifact kind
+`my-frontend-observer/visual-annotation`, schema version `1.0.0`. It stores one
+exact canonical source (a runtime observation, or an imported or approved
+external reference), the source coordinate space (runtime CSS pixels or
+reference-image pixels), and bounded structured items. Each item has a stable
+`annotationItemId`, one mark (point, rectangle, line, arrow, or note), an
+optional explicit association, and an interpretation. A revision sets
+`supersedesAnnotationId` and never rewrites its parent. The overlay SVG is
+derived from the artifact and verified before it is served.
+
+**An annotation is not a contract.** Saving an annotation never creates a
+contract clause, a reference requirement, or a PASS/FAIL rule. Marks and
+visible pixels are evidence. Overlap between a mark and a target or region is
+not ownership and never creates an association.
+
+**Interpretation states**: `uninterpreted`, `candidate`, and `confirmed`.
+Confirmation is explicit and records `confirmedAt`. Editing the mark,
+association, or intent of a confirmed item withdraws the confirmation.
+
+**Runtime intent to contract**:
+
+- Only selected, confirmed, supported runtime intent is promoted. Promotion
+  creates one normal canonical `PerChangeContract` through the existing
+  contract persistence service.
+- Supported mappings use the existing `ContractPrimitive` vocabulary only.
+  `move` maps to `property-increases`/`property-decreases` on `x` or `y`.
+  `resize` maps to `property-increases`/`property-decreases` on `width` or
+  `height`. `preserve` maps to `property-unchanged-within-tolerance` for a
+  target property, or to `relationship-unchanged` for an explicitly associated
+  canonical relationship.
+- Categories are the canonical `requested`, `expected-dependent` (with a
+  required `required` or `permitted` mode), `protected`, and `preserved`.
+  `unexpected` is never authored; it stays evaluator-derived.
+- `remove` can be confirmed and saved, but it is not promotable in v0.9. The
+  contract vocabulary has no target-absent primitive, and no approximate
+  clause is fabricated.
+- `inspect` intent and notes are informational and never promoted.
+- Each clause's `supportingEvidence` records the annotation source and item
+  paths. Promotion never activates the contract unless explicitly requested,
+  and it never approves a baseline.
+
+**Reference intent to a new reference revision**:
+
+- Only selected, confirmed `reference-region` (`create` or `refine`) and
+  `reference-requirement` items are materialized. `inspect` and
+  `asset-sensitive` intent stay informational.
+- The result is a new imported `ExternalReferenceArtifact`, created through the
+  existing canonical import service. It supersedes the selected source
+  reference (the approved reference id when the source is approved) and has
+  lifecycle `imported`. It is never approved automatically.
+- Source regions keep their order. A refine replaces the rectangle of an
+  existing source region and keeps its id. Creates are appended in selection
+  order. Duplicate creates, duplicate refines, and create-then-refine in one
+  request are rejected.
+- Source requirements stay first with identical recomputed ids. Selected
+  requirements are appended in selection order and validated against the final
+  regions. A selected relationship requirement must still hold for the final
+  geometry. Measurement requirements store only the subject and tolerance.
+- Applicability, label, and the exact source image bytes are preserved. The
+  source reference is never modified, and project reference acceptance is not
+  changed.
+
+Existing contract, reference relationship, adequacy, and fidelity evaluators
+remain the only source of verdicts. v0.9 adds no annotation evaluator.
 
 ## Approved v0.1 design inputs