@dailephd/my-frontend-observer 0.10.0 → 0.10.1

package/docs/reports/v0.7-reference-binding-prompt5.md

@@ -1,223 +1,223 @@
-# v0.7 Prompt 5 — Explicit Reference-Region ↔ Runtime-Target Binding
-
-**VERDICT: PASS_V0_7_REFERENCE_BINDING_PROMPT5**
-
-## Repository / branch / heads
-
-- Repository: `my-frontend-observer` (path: `Z:\Users\newuser\Projects\my-frontend-observer`)
-- Branch: `implementation/v0.7-reference-binding`, branched from the exact completed Prompt 4 HEAD
-- Starting HEAD (this prompt's branch point): `023feccac2b4255a119282d359782691b4734bce` (Prompt 4 report commit)
-- Prompt 4 base HEAD confirmed to contain both required commits: `4da60be` (implementation) and `023fecc` (report) — verified via `git log --oneline` before branching.
-- Implementation commit (this prompt): `74cc148f6b4ccda1c2a394634a8e9d5de26285dd` — "Add v0.7 Prompt 5 explicit reference-region <-> runtime-target binding"
-- Ending HEAD (after this report is committed): the report commit that follows this file's commit.
-
-## Git status
-
-Preflight (`git status --short`) showed a clean working tree on `implementation/v0.7-reference-compatibility` at the exact Prompt 4 report HEAD; `git stash list` showed exactly the one preserved Prompt 1 stray-fork-writes entry. The branch was created from that HEAD with `git checkout -b implementation/v0.7-reference-binding` and ancestry verified with `git merge-base --is-ancestor 023fecc HEAD`. No unrelated dirty state was present at any point; no reset/clean/discard operation was used; the Prompt 1 stash was neither applied nor dropped. Post-implementation `git status --short` is clean except for this report file (staged and committed separately, per convention).
-
-## Tooling
-
-- Resolved latest published `@dailephd/my-dev-kit`: `1.12.3` (via `npm view @dailephd/my-dev-kit version`), pinned exactly via `npx -y @dailephd/my-dev-kit@1.12.3`.
-- Fresh Prompt 5 repository index built under a repository-local root (per this prompt's "project-contained workflow state" requirement, not `C:\`): `.my-dev-kit-context/index-prompt5/` (`manifest.json`, `symbol-index.json`, `code-graph.json`, `call-graph.json`; 56 files, 851 symbols indexed). This index was not reused from Prompt 1–4's indexes — a fresh retrieval was performed at execution start.
-- `.gitignore` extended with `.my-dev-kit-context/` and `.my-dev-kit-workflow/` (alongside the pre-existing `.my-dev-kit/`/`.my-dev-kit-orchestrator/` entries) so this and future prompts' workflow-owned state never appears as stageable.
-
-## Prompt 1–4 contracts verified
-
-Read directly (source, not the fresh index's summaries alone) before writing any code:
-
-- `src/domain/externalReference.ts` / `externalReferenceIdentity.ts` — confirmed `ExternalReferenceArtifact`'s `regions?`/`requirements?`/`applicability?` shape, both lifecycle variants, and `isValidExternalReferenceArtifact`'s existing structural gate (reused directly, not reimplemented).
-- `src/domain/externalReferenceRegions.ts` — confirmed `ReferenceRegion.id` (Prompt 2's region identity: no separate identity-hashing function exists for regions, just the authored `id` string with `REFERENCE_REGION_ID_PATTERN` and case-insensitive uniqueness) — reused verbatim as the reference-side half of a binding declaration.
-- `src/domain/externalReferenceRequirements.ts` — confirmed the exact precedent for "a reference to an unknown region id is a structural validation failure at authoring time, not a per-item unavailable result" (`regionIds`/`byId` lowercase-keyed lookups, `isValidReferenceRequirements` rejecting the whole collection on an unknown region reference), and the "no two requirements may share the same structural subject" duplicate/conflict rule — both reused as direct design precedent for binding-declaration validation.
-- `src/domain/externalReferenceCompatibility.ts` (Prompt 4) — confirmed `evaluateReferenceCandidateCompatibility`'s exact signature and `ReferenceCandidateCompatibilityResult` shape; reused verbatim as this prompt's compatibility gate.
-- `src/domain/comparisonEngine.ts` (v0.4) — confirmed the module-private `targetPresence(record): 'matched'|'not-found'|'ambiguous'|'unavailable'` helper, already the canonical rule v0.4's own before/after target comparison uses to read a `TargetEvidenceRecord`'s resolution outcome.
-- `src/domain/schema.ts` (v0.1/v0.2) — confirmed `TargetSelectionStatus = 'matched'|'not-found'|'ambiguous'|'unavailable'`, `TargetResolution`, `TargetEvidenceRecord` (keyed by exact configured target name in `ObservationArtifact.targetEvidence`), and `TargetVisibility` (a wholly separate concept from `TargetSelectionStatus` — visibility is never one of the four resolution states).
-- `src/request/request.ts` (v0.1/v0.2) — confirmed `NamedTarget { name, locators }` as the stable observer-owned runtime target identity, `TARGET_NAME_RE = /^[A-Za-z0-9_-]{1,64}$/` (private, mirrored independently rather than imported), and the case-insensitive target-name-resolution convention already used for `target-scroll-by`.
-- `src/domain/boundedAgentContextCorrelation.ts` (v0.6) — read in full; confirmed the uncertainty-handling discipline (never hide competing candidates, never guess through ambiguity, deterministic candidate/target ordering by sorted id rather than input order, count-based status derivation: zero candidates → `unavailable`, one → `correlated`, more than one → `ambiguous`) reused as *architectural discipline* only — v0.6's own `correlated`/`ambiguous`/`unavailable` correlation-status vocabulary was deliberately **not** reused verbatim, since it describes a different evidence boundary (ranking static candidates for one runtime target) than binding (resolving one runtime target's own existence for one declared region correspondence).
-
-## v0.2 runtime-target precedent
-
-The stable runtime target identity is `NamedTarget.name` (a bounded `^[A-Za-z0-9_-]{1,64}$` label), matched against `ObservationArtifact.requestConfig.targets` and used to key `ObservationArtifact.targetEvidence`. This prompt binds only to that name — never to a CSS selector, a Playwright locator, a DOM node handle, a source file, a React component name, or a my-dev-kit node id. Target-name matching in `evaluateReferenceRuntimeBindings` is case-insensitive, mirroring the exact convention already used for `target-scroll-by` target resolution in `request/request.ts`; the exact configured `name` (original case) is then used to index `targetEvidence`, matching how that record is actually keyed by `src/browser/evidenceCapture.ts`.
-
-## v0.6 uncertainty precedent
-
-Reused as architectural discipline (never guess through ambiguity, never silently prefer a "first" candidate/result, deterministic ordering by declared/sorted identity rather than input order, explicit unavailable-vs-ambiguous distinction) — not as a literal status-vocabulary reuse. `evaluateReferenceRuntimeBindings` never collapses an ambiguous v0.2 target resolution into `bound`, and never fabricates a binding when the underlying evidence is missing.
-
-## Binding model
-
-One new pure domain module: `src/domain/externalReferenceRuntimeBinding.ts`.
-
-```ts
-interface ReferenceRuntimeBindingDeclaration {
-  referenceRegion: string; // Prompt 2 ReferenceRegion.id
-  runtimeTarget: string;   // v0.2 NamedTarget.name
-}
-
-function isValidReferenceRuntimeBindingDeclarations(
-  value: unknown,
-  reference: ExternalReferenceArtifact,
-): { valid: true } | { valid: false; reason: string };
-
-function evaluateReferenceRuntimeBindings(
-  reference: ExternalReferenceArtifact,
-  candidate: ObservationArtifact,
-  declarations: readonly ReferenceRuntimeBindingDeclaration[],
-): { ok: true; evaluation: ReferenceRuntimeBindingEvaluation } | { ok: false; reason: string };
-```
-
-The binding declaration is explicit user/configuration input at every point — the module contains no code path that derives a correspondence from geometry, pixel content, matching name strings, matching text, or source code. A reference region id and a runtime target name that happen to share the same string value bind to each other only when an explicit declaration says so (verified directly by a dedicated test comparing the same observation/reference pair with and without the declaration).
-
-## Exact status vocabulary
-
-`REFERENCE_RUNTIME_BINDING_STATUSES = ['bound', 'ambiguous', 'unavailable'] as const`. No fourth "incompatible" status was added — per the task's own guidance (§14), Prompt 4's compatibility is represented separately (see below), never folded into a binding-local status enum.
-
-Reason codes (present only when `status !== 'bound'`): `runtime-target-not-configured`, `runtime-target-not-found`, `runtime-target-ambiguous`, `runtime-target-evidence-unavailable`.
-
-## Compatibility-gating behavior
-
-`evaluateReferenceRuntimeBindings` calls `evaluateReferenceCandidateCompatibility(reference, candidate)` exactly once, before evaluating any individual declaration. If the returned `compatibility.state === 'incomparable'`, the function returns `ok: true` with `bindings: []` and the full `compatibility` result embedded in `ReferenceRuntimeBindingEvaluation.compatibility` — the caller reads the blocker from that field. No per-declaration result is fabricated in this case (verified by behavior-F test: an incompatible viewport pair produces zero bindings, never a bound result). When `compatibility.state` is `comparable` or `comparable-with-warnings`, every declaration is evaluated normally. Compatibility rules (viewport/theme/application-state/authenticated-state comparison) are never recomputed or duplicated inside this module.
-
-## Reference-region identity behavior
-
-Reused exactly as Prompt 2 defined it: `ReferenceRegion.id`, matched case-insensitively (mirroring the existing region-uniqueness/requirement-region-reference convention). No new reference-region identity system was created. A declaration naming a `referenceRegion` not present in `reference.regions` (or a reference with no `regions` field at all) fails the **entire** evaluation closed at the structural-validation stage — `evaluateReferenceRuntimeBindings` returns `ok: false` before a candidate observation is even consulted, mirroring Prompt 3's exact "unknown region reference is a structural authoring-time failure" precedent for requirements.
-
-## Runtime-target identity behavior
-
-Reused exactly as v0.2 defined it: `NamedTarget.name`, matched case-insensitively against `candidate.requestConfig.targets`, then the exact configured name is used to index `candidate.targetEvidence`. Runtime-target *availability* (as opposed to reference-region *existence*) is evaluated per-candidate, inside `evaluateReferenceRuntimeBindings` itself, not during the candidate-independent structural validation pass — the same declaration can legitimately be `bound` against one candidate and `unavailable` against another.
-
-## Target-resolution-state handling
-
-`targetPresence` (v0.4 `comparisonEngine.ts`, additively exported this prompt alongside the already-exported `assessOptionalComparabilityDimension`) is the single reused rule for reading a `TargetEvidenceRecord`'s resolution:
-
-| `targetPresence` outcome | Binding status | Reason code |
-|---|---|---|
-| `matched` | `bound` | — |
-| `ambiguous` | `ambiguous` | `runtime-target-ambiguous` |
-| `not-found` | `unavailable` | `runtime-target-not-found` |
-| `unavailable` (no usable resolution evidence, or no record at all) | `unavailable` | `runtime-target-evidence-unavailable` |
-
-A fifth situation exists only at the binding-evaluation boundary itself, not inside `targetPresence`: a declared `runtimeTarget` that was never part of the candidate's own `requestConfig.targets` at all → `unavailable` / `runtime-target-not-configured`, resolved without ever dynamically searching the page (the evaluator consumes only the already-captured `ObservationArtifact`).
-
-## Hidden-target decision
-
-A uniquely resolved (`matched`) but hidden target (`TargetVisibility.visible === false`) is still reported `bound` — visibility is carried only as provenance (`targetVisible`) and never changes `status`. Rationale, documented in the module and in `docs/CONTRACTS.md`: binding identity ("does a stable correspondence exist") and fidelity evaluability ("can this evidence actually be used to check the design") are distinct questions; this prompt answers only the former, leaving the latter to Prompt 6. Verified by a dedicated test (`Q: a hidden but uniquely resolved runtime target is still reported bound, with targetVisible: false as provenance`).
-
-## Duplicate/conflicting binding behavior
-
-No two declarations may name the same `referenceRegion` (case-insensitively), whether their `runtimeTarget` values agree (an exact duplicate) or disagree (a conflict) — both fail the whole batch identically at structural-validation time, `ok: false`, never silently resolved by keeping the first declaration. This mirrors Prompt 3's "no two requirements may share the same structural subject, regardless of category" rule exactly. Verified by dedicated tests for both the exact-duplicate case (I) and the conflicting-target case (J).
-
-## Multiple-regions-to-one-target decision
-
-**Allowed, deliberately.** Several distinct reference regions may each declare a binding to the same `runtimeTarget` (e.g. two design sub-regions, such as a header's logo area and its nav area, both corresponding conceptually to one runtime container element). This is documented as a legitimate correspondence, unlike the reverse (one region needing several runtime targets), which is prohibited because it would be inherently ambiguous which target represents that region — the "one region, one explicit primary target" rule from §13. Verified by a dedicated test (K).
-
-## Bounds
-
-`MAX_REFERENCE_RUNTIME_BINDINGS = 20`, mirroring `MAX_REFERENCE_REGIONS`'s existing bound — a binding-declaration collection is authoring input over the same region set, so the same cap applies. Independently owned (not imported), consistent with the repository's established "coincidentally equal, independently owned bound" convention (e.g. `MAX_REFERENCE_REGIONS`/`MAX_TARGETS` already share the value 20 without being structurally coupled). Verified: exactly 20 declarations accepted, 21 rejected.
-
-## Deterministic ordering
-
-`bindings` in the evaluation result preserves the authored order of the `declarations` array passed in — never a sort by any derived key, mirroring the "authored order is semantic" convention already established for regions (Prompt 2) and requirements (Prompt 3). Verified by a dedicated test asserting result order matches declaration order even when it does not match the reference's own region-authoring order.
-
-## Identity decision
-
-**No new identity-hashing function was introduced.** Unlike `buildRequestIdentity`/`buildExternalReferenceRequestIdentity`, no deterministic content-hash identity is computed for a binding declaration or its evaluated result. This mirrors Prompt 4's own `ReferenceCandidateCompatibilityResult`, which took the identical approach: provenance is carried as plain, already-deterministic fields (`referenceId`, `referenceRequestId`, `candidateObservationId`, `candidateRequestId`, plus each result's own `referenceRegion`/`runtimeTarget`) rather than a fifth hashing convention for a value this prompt never persists and never looks up by id. Because no identity function exists, path-independence (test L in the task's behavior model) holds trivially — there is no file-loading code in this prompt at all (see CLI decision below), so no path could ever reach identity even indirectly.
-
-## Persistence decision
-
-**No persisted artifact family was introduced.** `evaluateReferenceRuntimeBindings` is a pure, synchronous, on-demand function over an already-persisted `ExternalReferenceArtifact`, an already-persisted `ObservationArtifact`, and an in-memory declaration collection — it produces no `ExternalReferenceBindingArtifact` or equivalent. Rationale (same reasoning Prompt 4 already applied to its own compatibility result): the result is cheap to recompute deterministically from its three inputs, and persisting it would invite drift (a re-imported reference or re-observed candidate could silently disagree with a stale persisted binding record) with no corresponding benefit at this stage. This decision may be revisited only if Prompt 6's architecture proves persistence necessary — not assumed here.
-
-## Reference / observation artifact immutability
-
-Neither `ExternalReferenceArtifact` nor `ObservationArtifact` gained any new field in this prompt, and `evaluateReferenceRuntimeBindings` never mutates either input (verified by a dedicated deep-equality-snapshot test, N, covering the reference, the candidate, and the declaration input array all three). A design reference remains evaluable against multiple future candidates; a candidate observation remains evaluable against multiple future references — binding results are kept as downstream, candidate-specific, reference-specific derived evidence, never embedded back into either source artifact.
-
-## Public / programmatic interface
-
-Exported from `src/index.ts` (additive):
-- Types: `ReferenceRuntimeBindingStatus`, `ReferenceRuntimeBindingReasonCode`, `ReferenceRuntimeBindingDeclaration`, `ReferenceRuntimeBindingValidationResult`, `ReferenceRuntimeBindingResult`, `ReferenceRuntimeBindingEvaluation`, `EvaluateReferenceRuntimeBindingsResult`.
-- Values: `RUNTIME_TARGET_NAME_PATTERN`, `MAX_REFERENCE_RUNTIME_BINDINGS`, `REFERENCE_RUNTIME_BINDING_STATUSES`, `REFERENCE_RUNTIME_BINDING_REASON_CODES`, `isValidReferenceRuntimeBindingDeclarations`, `evaluateReferenceRuntimeBindings`.
-- Additionally, `TargetPresence`/`targetPresence` (previously module-private in `comparisonEngine.ts`) are now additively exported, since this new module reuses that exact function rather than duplicating its logic.
-
-No internal helper clutter is exported (`findConfiguredTargetName`, `evaluateOneBinding`, `isValidBindingDeclarationShape` all remain module-private).
-
-## CLI changes
-
-**None.** Per the task's explicit guidance (§37: "Do not add a standalone CLI command merely for symmetry... Prompt 6 may become the first public consumer"), no CLI command or config-file loader was added this prompt. The full capability is exposed only through the programmatic API above. `docs/COMMANDS.md` was therefore not touched.
-
-## Files changed
-
-New:
-- `src/domain/externalReferenceRuntimeBinding.ts`
-- `tests/unit/externalReferenceRuntimeBinding.test.ts`
-
-Modified:
-- `src/domain/comparisonEngine.ts` (additively exported `targetPresence`/`TargetPresence`, previously module-private; zero behavior change)
-- `src/index.ts` (public export surface for the above)
-- `docs/ARCHITECTURE.md`, `docs/CONTRACTS.md`, `docs/WORKFLOWS.md`
-- `.gitignore` (added `.my-dev-kit-context/`, `.my-dev-kit-workflow/`)
-
-## Tests
-
-889 unit tests total (857 pre-existing + 32 new), all pure domain-level tests — zero Chromium launches for binding evaluation itself, per the task's explicit requirement. New coverage in `tests/unit/externalReferenceRuntimeBinding.test.ts` includes:
-
-- `isValidReferenceRuntimeBindingDeclarations`: valid single/empty declaration, non-array rejection, exact-bound acceptance (20) and one-over-bound rejection (21), malformed shape rejection (missing field/wrong type/unknown field), unknown reference region (behavior B), reference with no regions at all (behavior O), exact-duplicate rejection (behavior I), conflicting-target rejection (behavior J), multiple-regions-to-one-target acceptance (behavior K), unused-region tolerance (behavior P), case-insensitive region matching.
-- `evaluateReferenceRuntimeBindings`: valid binding with differing ids (behaviors A/H), same-string-ids-require-explicit-declaration (behavior G, both with and without the declaration), unknown-region whole-batch failure (behavior B), unknown/not-configured runtime target (behavior C), ambiguous runtime target (behavior D), not-found vs. evidence-unavailable distinction, incompatible reference/candidate blocks all bindings (behavior F), matching compatibility permits evaluation, hidden-target bound-with-provenance (behavior Q), deterministic authored-order preservation and pure-function repeatability (behavior M), full three-input immutability (behavior N), case-insensitive runtime-target-name resolution, full provenance carry-through, fail-closed on a structurally invalid reference or candidate artifact, and absence of any source-ownership-style field in the result (`sourceOwner`/`sourceFile`/`component`/`symbol`/`causedBy`).
-
-## Validation results
-
-All commands run from the repository root, after the implementation commit:
-
-- `npm run typecheck` — pass, zero errors.
-- `npm run lint` — pass, zero errors/warnings.
-- `npm test` — 46 test files, 889 tests, all pass.
-- `npm run build` — pass, clean `tsc` compile.
-- `npm run check:docs` — pass (17 required files present, `ROADMAP.md` format intact — no implementation batches added).
-- `git diff --check` — exit 0, no whitespace errors.
-- `npm pack --dry-run` — pass; `dist/domain/externalReferenceRuntimeBinding.{js,d.ts,js.map}` confirmed present in the tarball listing (public exports changed, so this was run per the task's requirement).
-- `npm run test:security` — pass (5 + 63 = 68 tests: `policy.test.ts` + real-Chromium `chromiumAdapter.test.ts`), run because a new public input surface (`ReferenceRuntimeBindingDeclaration`) was added.
-- `npm run test:browser` — pass (9 files, 120 tests, real Chromium), run as full regression confirmation per established repository policy, even though Prompt 5 itself has no Chromium dependency.
-
-## Regression results
-
-- Prompt 1 artifact/lifecycle: unaffected — `externalReference.ts` untouched this prompt.
-- Prompt 2 regions/relationships: unaffected — `externalReferenceRegions.ts`/`externalReferenceRegionRelationships.ts` untouched; `REFERENCE_REGION_ID_PATTERN` only imported, never modified.
-- Prompt 3 requirements/adequacy: unaffected — `externalReferenceRequirements.ts` untouched.
-- Prompt 4 state/compatibility: unaffected — `externalReferenceCompatibility.ts`, `explicitState.ts`, `externalReferenceApplicability.ts` untouched; `evaluateReferenceCandidateCompatibility` called, never modified.
-- v0.2 runtime target identity/resolution: unaffected — `request/request.ts`, `schema.ts`, `browser/evidenceCapture.ts` untouched.
-- v0.4 comparison: unaffected in behavior — `comparisonEngine.ts`'s only change is exporting a previously-private function (`targetPresence`) verbatim; every existing caller and every existing test of `evaluateComparability`/`compareObservations`/`compareTargetConfiguration` continues to pass unchanged.
-- v0.5 contracts: unaffected — no file in `frontendContracts*.ts` touched.
-- v0.6 runtime/static correlation: unaffected — `boundedAgentContext*.ts` untouched; its status vocabulary/discipline was read for precedent only, never imported or modified.
-- Full unit (889/889), browser (120/120), and security (68/68) suites all pass with zero regressions.
-
-## Security impact
-
-- No new external input surface beyond an in-memory, caller-supplied declaration array (no file, no CLI flag, no network call in this prompt) — the smallest possible surface, since no CLI/config-file loader was added.
-- `evaluateReferenceRuntimeBindings` performs no filesystem access, no network access, and no browser/Chromium invocation of any kind.
-- `test:security` (policy + real-Chromium adapter tests) re-run and passing, confirming no regression to the existing safety/navigation policy surface (untouched by this prompt).
-
-## Documentation changes
-
-- `docs/CONTRACTS.md` — new "v0.7 Prompt 5 explicit reference-region ↔ runtime-target binding" section (full type shapes, key rules, status-mapping table equivalent in prose, hidden-target/duplicate/multiple-regions decisions, persistence/identity decisions, CLI-surface decision).
-- `docs/ARCHITECTURE.md` — new paragraph in the "Planned v0.7–v0.10" section describing the Prompt 5 module addition, its reuse of Prompt 4's compatibility gate and v0.4's `targetPresence`, and its architectural-discipline-only (not vocabulary) reuse of v0.6's uncertainty handling.
-- `docs/WORKFLOWS.md` — "Current external-reference foundation workflow" retitled to "Prompts 1-5" and extended with a paragraph describing `evaluateReferenceRuntimeBindings`.
-- `docs/COMMANDS.md` — not touched (no CLI surface change this prompt).
-
-## Tooling incidents
-
-None. No orchestrator was invoked (direct-implementation mode used throughout, consistent with Prompts 2–5); no background/speculative subagent writes occurred; the Prompt 1 stray-fork-writes stash remains untouched, unapplied, and unmined as precedent.
-
-## Out-of-scope confirmation
-
-This prompt implements no automatic target matching, no computer vision, no screenshot segmentation, no OCR, no fuzzy matching, no geometry-based matching, no source-correlation changes, no source ownership, no reference/candidate geometry delta, no spacing delta, no relationship fidelity evaluation, no selected-requirement evaluation, no fidelity PASS/FAIL, no style fidelity, no image similarity, no bounded correction packet, no coding-agent context changes or invocation, no source edits, no correction loop, no viewer, and no annotation. `evaluateReferenceRuntimeBindings` reads only `reference.regions` (for structural validation), `reference.applicability` (via the reused compatibility gate), and `candidate.requestConfig.targets`/`candidate.targetEvidence` — it never reads `reference.requirements`, never compares geometry, and never touches source code or my-dev-kit retrieval of any kind.
-
-## Known limitations
-
-- A binding declaration supports exactly one `runtimeTarget` per `referenceRegion` — there is no "candidate alternatives" mechanism (deliberately; the task's own guidance treats this as the smallest, cleanest representation, and any future need for ranked/multiple candidate targets per region is left to a later prompt to design explicitly, not improvised here).
-- No CLI/config-file surface exists yet for authoring binding declarations outside of direct programmatic use — deferred to Prompt 6 per the task's own guidance.
-- `targetVisible` provenance is populated only when the underlying `TargetVisibility` evidence is itself available; a `bound` result for a target whose visibility evidence is unavailable simply omits the field rather than guessing a value.
-
-## Remaining risks
-
-- None identified that block this prompt's own scope. The primary forward consideration for Prompt 6 (structured fidelity evaluation) is how it will consume `ReferenceRuntimeBindingEvaluation.bindings` together with Prompt 3's per-requirement expectations to determine which selected requirements have sufficient bound evidence for evaluation — flagged for that prompt's own precedent review, not preempted here.
-
-## Exact next action
-
-v0.7 Prompt 6 — structured reference-vs-candidate fidelity evaluation.
+# v0.7 Prompt 5 — Explicit Reference-Region ↔ Runtime-Target Binding
+
+**VERDICT: PASS_V0_7_REFERENCE_BINDING_PROMPT5**
+
+## Repository / branch / heads
+
+- Repository: `my-frontend-observer` (path: `Z:\Users\newuser\Projects\my-frontend-observer`)
+- Branch: `implementation/v0.7-reference-binding`, branched from the exact completed Prompt 4 HEAD
+- Starting HEAD (this prompt's branch point): `023feccac2b4255a119282d359782691b4734bce` (Prompt 4 report commit)
+- Prompt 4 base HEAD confirmed to contain both required commits: `4da60be` (implementation) and `023fecc` (report) — verified via `git log --oneline` before branching.
+- Implementation commit (this prompt): `74cc148f6b4ccda1c2a394634a8e9d5de26285dd` — "Add v0.7 Prompt 5 explicit reference-region <-> runtime-target binding"
+- Ending HEAD (after this report is committed): the report commit that follows this file's commit.
+
+## Git status
+
+Preflight (`git status --short`) showed a clean working tree on `implementation/v0.7-reference-compatibility` at the exact Prompt 4 report HEAD; `git stash list` showed exactly the one preserved Prompt 1 stray-fork-writes entry. The branch was created from that HEAD with `git checkout -b implementation/v0.7-reference-binding` and ancestry verified with `git merge-base --is-ancestor 023fecc HEAD`. No unrelated dirty state was present at any point; no reset/clean/discard operation was used; the Prompt 1 stash was neither applied nor dropped. Post-implementation `git status --short` is clean except for this report file (staged and committed separately, per convention).
+
+## Tooling
+
+- Resolved latest published `@dailephd/my-dev-kit`: `1.12.3` (via `npm view @dailephd/my-dev-kit version`), pinned exactly via `npx -y @dailephd/my-dev-kit@1.12.3`.
+- Fresh Prompt 5 repository index built under a repository-local root (per this prompt's "project-contained workflow state" requirement, not `C:\`): `.my-dev-kit-context/index-prompt5/` (`manifest.json`, `symbol-index.json`, `code-graph.json`, `call-graph.json`; 56 files, 851 symbols indexed). This index was not reused from Prompt 1–4's indexes — a fresh retrieval was performed at execution start.
+- `.gitignore` extended with `.my-dev-kit-context/` and `.my-dev-kit-workflow/` (alongside the pre-existing `.my-dev-kit/`/`.my-dev-kit-orchestrator/` entries) so this and future prompts' workflow-owned state never appears as stageable.
+
+## Prompt 1–4 contracts verified
+
+Read directly (source, not the fresh index's summaries alone) before writing any code:
+
+- `src/domain/externalReference.ts` / `externalReferenceIdentity.ts` — confirmed `ExternalReferenceArtifact`'s `regions?`/`requirements?`/`applicability?` shape, both lifecycle variants, and `isValidExternalReferenceArtifact`'s existing structural gate (reused directly, not reimplemented).
+- `src/domain/externalReferenceRegions.ts` — confirmed `ReferenceRegion.id` (Prompt 2's region identity: no separate identity-hashing function exists for regions, just the authored `id` string with `REFERENCE_REGION_ID_PATTERN` and case-insensitive uniqueness) — reused verbatim as the reference-side half of a binding declaration.
+- `src/domain/externalReferenceRequirements.ts` — confirmed the exact precedent for "a reference to an unknown region id is a structural validation failure at authoring time, not a per-item unavailable result" (`regionIds`/`byId` lowercase-keyed lookups, `isValidReferenceRequirements` rejecting the whole collection on an unknown region reference), and the "no two requirements may share the same structural subject" duplicate/conflict rule — both reused as direct design precedent for binding-declaration validation.
+- `src/domain/externalReferenceCompatibility.ts` (Prompt 4) — confirmed `evaluateReferenceCandidateCompatibility`'s exact signature and `ReferenceCandidateCompatibilityResult` shape; reused verbatim as this prompt's compatibility gate.
+- `src/domain/comparisonEngine.ts` (v0.4) — confirmed the module-private `targetPresence(record): 'matched'|'not-found'|'ambiguous'|'unavailable'` helper, already the canonical rule v0.4's own before/after target comparison uses to read a `TargetEvidenceRecord`'s resolution outcome.
+- `src/domain/schema.ts` (v0.1/v0.2) — confirmed `TargetSelectionStatus = 'matched'|'not-found'|'ambiguous'|'unavailable'`, `TargetResolution`, `TargetEvidenceRecord` (keyed by exact configured target name in `ObservationArtifact.targetEvidence`), and `TargetVisibility` (a wholly separate concept from `TargetSelectionStatus` — visibility is never one of the four resolution states).
+- `src/request/request.ts` (v0.1/v0.2) — confirmed `NamedTarget { name, locators }` as the stable observer-owned runtime target identity, `TARGET_NAME_RE = /^[A-Za-z0-9_-]{1,64}$/` (private, mirrored independently rather than imported), and the case-insensitive target-name-resolution convention already used for `target-scroll-by`.
+- `src/domain/boundedAgentContextCorrelation.ts` (v0.6) — read in full; confirmed the uncertainty-handling discipline (never hide competing candidates, never guess through ambiguity, deterministic candidate/target ordering by sorted id rather than input order, count-based status derivation: zero candidates → `unavailable`, one → `correlated`, more than one → `ambiguous`) reused as *architectural discipline* only — v0.6's own `correlated`/`ambiguous`/`unavailable` correlation-status vocabulary was deliberately **not** reused verbatim, since it describes a different evidence boundary (ranking static candidates for one runtime target) than binding (resolving one runtime target's own existence for one declared region correspondence).
+
+## v0.2 runtime-target precedent
+
+The stable runtime target identity is `NamedTarget.name` (a bounded `^[A-Za-z0-9_-]{1,64}$` label), matched against `ObservationArtifact.requestConfig.targets` and used to key `ObservationArtifact.targetEvidence`. This prompt binds only to that name — never to a CSS selector, a Playwright locator, a DOM node handle, a source file, a React component name, or a my-dev-kit node id. Target-name matching in `evaluateReferenceRuntimeBindings` is case-insensitive, mirroring the exact convention already used for `target-scroll-by` target resolution in `request/request.ts`; the exact configured `name` (original case) is then used to index `targetEvidence`, matching how that record is actually keyed by `src/browser/evidenceCapture.ts`.
+
+## v0.6 uncertainty precedent
+
+Reused as architectural discipline (never guess through ambiguity, never silently prefer a "first" candidate/result, deterministic ordering by declared/sorted identity rather than input order, explicit unavailable-vs-ambiguous distinction) — not as a literal status-vocabulary reuse. `evaluateReferenceRuntimeBindings` never collapses an ambiguous v0.2 target resolution into `bound`, and never fabricates a binding when the underlying evidence is missing.
+
+## Binding model
+
+One new pure domain module: `src/domain/externalReferenceRuntimeBinding.ts`.
+
+```ts
+interface ReferenceRuntimeBindingDeclaration {
+  referenceRegion: string; // Prompt 2 ReferenceRegion.id
+  runtimeTarget: string;   // v0.2 NamedTarget.name
+}
+
+function isValidReferenceRuntimeBindingDeclarations(
+  value: unknown,
+  reference: ExternalReferenceArtifact,
+): { valid: true } | { valid: false; reason: string };
+
+function evaluateReferenceRuntimeBindings(
+  reference: ExternalReferenceArtifact,
+  candidate: ObservationArtifact,
+  declarations: readonly ReferenceRuntimeBindingDeclaration[],
+): { ok: true; evaluation: ReferenceRuntimeBindingEvaluation } | { ok: false; reason: string };
+```
+
+The binding declaration is explicit user/configuration input at every point — the module contains no code path that derives a correspondence from geometry, pixel content, matching name strings, matching text, or source code. A reference region id and a runtime target name that happen to share the same string value bind to each other only when an explicit declaration says so (verified directly by a dedicated test comparing the same observation/reference pair with and without the declaration).
+
+## Exact status vocabulary
+
+`REFERENCE_RUNTIME_BINDING_STATUSES = ['bound', 'ambiguous', 'unavailable'] as const`. No fourth "incompatible" status was added — per the task's own guidance (§14), Prompt 4's compatibility is represented separately (see below), never folded into a binding-local status enum.
+
+Reason codes (present only when `status !== 'bound'`): `runtime-target-not-configured`, `runtime-target-not-found`, `runtime-target-ambiguous`, `runtime-target-evidence-unavailable`.
+
+## Compatibility-gating behavior
+
+`evaluateReferenceRuntimeBindings` calls `evaluateReferenceCandidateCompatibility(reference, candidate)` exactly once, before evaluating any individual declaration. If the returned `compatibility.state === 'incomparable'`, the function returns `ok: true` with `bindings: []` and the full `compatibility` result embedded in `ReferenceRuntimeBindingEvaluation.compatibility` — the caller reads the blocker from that field. No per-declaration result is fabricated in this case (verified by behavior-F test: an incompatible viewport pair produces zero bindings, never a bound result). When `compatibility.state` is `comparable` or `comparable-with-warnings`, every declaration is evaluated normally. Compatibility rules (viewport/theme/application-state/authenticated-state comparison) are never recomputed or duplicated inside this module.
+
+## Reference-region identity behavior
+
+Reused exactly as Prompt 2 defined it: `ReferenceRegion.id`, matched case-insensitively (mirroring the existing region-uniqueness/requirement-region-reference convention). No new reference-region identity system was created. A declaration naming a `referenceRegion` not present in `reference.regions` (or a reference with no `regions` field at all) fails the **entire** evaluation closed at the structural-validation stage — `evaluateReferenceRuntimeBindings` returns `ok: false` before a candidate observation is even consulted, mirroring Prompt 3's exact "unknown region reference is a structural authoring-time failure" precedent for requirements.
+
+## Runtime-target identity behavior
+
+Reused exactly as v0.2 defined it: `NamedTarget.name`, matched case-insensitively against `candidate.requestConfig.targets`, then the exact configured name is used to index `candidate.targetEvidence`. Runtime-target *availability* (as opposed to reference-region *existence*) is evaluated per-candidate, inside `evaluateReferenceRuntimeBindings` itself, not during the candidate-independent structural validation pass — the same declaration can legitimately be `bound` against one candidate and `unavailable` against another.
+
+## Target-resolution-state handling
+
+`targetPresence` (v0.4 `comparisonEngine.ts`, additively exported this prompt alongside the already-exported `assessOptionalComparabilityDimension`) is the single reused rule for reading a `TargetEvidenceRecord`'s resolution:
+
+| `targetPresence` outcome | Binding status | Reason code |
+|---|---|---|
+| `matched` | `bound` | — |
+| `ambiguous` | `ambiguous` | `runtime-target-ambiguous` |
+| `not-found` | `unavailable` | `runtime-target-not-found` |
+| `unavailable` (no usable resolution evidence, or no record at all) | `unavailable` | `runtime-target-evidence-unavailable` |
+
+A fifth situation exists only at the binding-evaluation boundary itself, not inside `targetPresence`: a declared `runtimeTarget` that was never part of the candidate's own `requestConfig.targets` at all → `unavailable` / `runtime-target-not-configured`, resolved without ever dynamically searching the page (the evaluator consumes only the already-captured `ObservationArtifact`).
+
+## Hidden-target decision
+
+A uniquely resolved (`matched`) but hidden target (`TargetVisibility.visible === false`) is still reported `bound` — visibility is carried only as provenance (`targetVisible`) and never changes `status`. Rationale, documented in the module and in `docs/CONTRACTS.md`: binding identity ("does a stable correspondence exist") and fidelity evaluability ("can this evidence actually be used to check the design") are distinct questions; this prompt answers only the former, leaving the latter to Prompt 6. Verified by a dedicated test (`Q: a hidden but uniquely resolved runtime target is still reported bound, with targetVisible: false as provenance`).
+
+## Duplicate/conflicting binding behavior
+
+No two declarations may name the same `referenceRegion` (case-insensitively), whether their `runtimeTarget` values agree (an exact duplicate) or disagree (a conflict) — both fail the whole batch identically at structural-validation time, `ok: false`, never silently resolved by keeping the first declaration. This mirrors Prompt 3's "no two requirements may share the same structural subject, regardless of category" rule exactly. Verified by dedicated tests for both the exact-duplicate case (I) and the conflicting-target case (J).
+
+## Multiple-regions-to-one-target decision
+
+**Allowed, deliberately.** Several distinct reference regions may each declare a binding to the same `runtimeTarget` (e.g. two design sub-regions, such as a header's logo area and its nav area, both corresponding conceptually to one runtime container element). This is documented as a legitimate correspondence, unlike the reverse (one region needing several runtime targets), which is prohibited because it would be inherently ambiguous which target represents that region — the "one region, one explicit primary target" rule from §13. Verified by a dedicated test (K).
+
+## Bounds
+
+`MAX_REFERENCE_RUNTIME_BINDINGS = 20`, mirroring `MAX_REFERENCE_REGIONS`'s existing bound — a binding-declaration collection is authoring input over the same region set, so the same cap applies. Independently owned (not imported), consistent with the repository's established "coincidentally equal, independently owned bound" convention (e.g. `MAX_REFERENCE_REGIONS`/`MAX_TARGETS` already share the value 20 without being structurally coupled). Verified: exactly 20 declarations accepted, 21 rejected.
+
+## Deterministic ordering
+
+`bindings` in the evaluation result preserves the authored order of the `declarations` array passed in — never a sort by any derived key, mirroring the "authored order is semantic" convention already established for regions (Prompt 2) and requirements (Prompt 3). Verified by a dedicated test asserting result order matches declaration order even when it does not match the reference's own region-authoring order.
+
+## Identity decision
+
+**No new identity-hashing function was introduced.** Unlike `buildRequestIdentity`/`buildExternalReferenceRequestIdentity`, no deterministic content-hash identity is computed for a binding declaration or its evaluated result. This mirrors Prompt 4's own `ReferenceCandidateCompatibilityResult`, which took the identical approach: provenance is carried as plain, already-deterministic fields (`referenceId`, `referenceRequestId`, `candidateObservationId`, `candidateRequestId`, plus each result's own `referenceRegion`/`runtimeTarget`) rather than a fifth hashing convention for a value this prompt never persists and never looks up by id. Because no identity function exists, path-independence (test L in the task's behavior model) holds trivially — there is no file-loading code in this prompt at all (see CLI decision below), so no path could ever reach identity even indirectly.
+
+## Persistence decision
+
+**No persisted artifact family was introduced.** `evaluateReferenceRuntimeBindings` is a pure, synchronous, on-demand function over an already-persisted `ExternalReferenceArtifact`, an already-persisted `ObservationArtifact`, and an in-memory declaration collection — it produces no `ExternalReferenceBindingArtifact` or equivalent. Rationale (same reasoning Prompt 4 already applied to its own compatibility result): the result is cheap to recompute deterministically from its three inputs, and persisting it would invite drift (a re-imported reference or re-observed candidate could silently disagree with a stale persisted binding record) with no corresponding benefit at this stage. This decision may be revisited only if Prompt 6's architecture proves persistence necessary — not assumed here.
+
+## Reference / observation artifact immutability
+
+Neither `ExternalReferenceArtifact` nor `ObservationArtifact` gained any new field in this prompt, and `evaluateReferenceRuntimeBindings` never mutates either input (verified by a dedicated deep-equality-snapshot test, N, covering the reference, the candidate, and the declaration input array all three). A design reference remains evaluable against multiple future candidates; a candidate observation remains evaluable against multiple future references — binding results are kept as downstream, candidate-specific, reference-specific derived evidence, never embedded back into either source artifact.
+
+## Public / programmatic interface
+
+Exported from `src/index.ts` (additive):
+- Types: `ReferenceRuntimeBindingStatus`, `ReferenceRuntimeBindingReasonCode`, `ReferenceRuntimeBindingDeclaration`, `ReferenceRuntimeBindingValidationResult`, `ReferenceRuntimeBindingResult`, `ReferenceRuntimeBindingEvaluation`, `EvaluateReferenceRuntimeBindingsResult`.
+- Values: `RUNTIME_TARGET_NAME_PATTERN`, `MAX_REFERENCE_RUNTIME_BINDINGS`, `REFERENCE_RUNTIME_BINDING_STATUSES`, `REFERENCE_RUNTIME_BINDING_REASON_CODES`, `isValidReferenceRuntimeBindingDeclarations`, `evaluateReferenceRuntimeBindings`.
+- Additionally, `TargetPresence`/`targetPresence` (previously module-private in `comparisonEngine.ts`) are now additively exported, since this new module reuses that exact function rather than duplicating its logic.
+
+No internal helper clutter is exported (`findConfiguredTargetName`, `evaluateOneBinding`, `isValidBindingDeclarationShape` all remain module-private).
+
+## CLI changes
+
+**None.** Per the task's explicit guidance (§37: "Do not add a standalone CLI command merely for symmetry... Prompt 6 may become the first public consumer"), no CLI command or config-file loader was added this prompt. The full capability is exposed only through the programmatic API above. `docs/COMMANDS.md` was therefore not touched.
+
+## Files changed
+
+New:
+- `src/domain/externalReferenceRuntimeBinding.ts`
+- `tests/unit/externalReferenceRuntimeBinding.test.ts`
+
+Modified:
+- `src/domain/comparisonEngine.ts` (additively exported `targetPresence`/`TargetPresence`, previously module-private; zero behavior change)
+- `src/index.ts` (public export surface for the above)
+- `docs/ARCHITECTURE.md`, `docs/CONTRACTS.md`, `docs/WORKFLOWS.md`
+- `.gitignore` (added `.my-dev-kit-context/`, `.my-dev-kit-workflow/`)
+
+## Tests
+
+889 unit tests total (857 pre-existing + 32 new), all pure domain-level tests — zero Chromium launches for binding evaluation itself, per the task's explicit requirement. New coverage in `tests/unit/externalReferenceRuntimeBinding.test.ts` includes:
+
+- `isValidReferenceRuntimeBindingDeclarations`: valid single/empty declaration, non-array rejection, exact-bound acceptance (20) and one-over-bound rejection (21), malformed shape rejection (missing field/wrong type/unknown field), unknown reference region (behavior B), reference with no regions at all (behavior O), exact-duplicate rejection (behavior I), conflicting-target rejection (behavior J), multiple-regions-to-one-target acceptance (behavior K), unused-region tolerance (behavior P), case-insensitive region matching.
+- `evaluateReferenceRuntimeBindings`: valid binding with differing ids (behaviors A/H), same-string-ids-require-explicit-declaration (behavior G, both with and without the declaration), unknown-region whole-batch failure (behavior B), unknown/not-configured runtime target (behavior C), ambiguous runtime target (behavior D), not-found vs. evidence-unavailable distinction, incompatible reference/candidate blocks all bindings (behavior F), matching compatibility permits evaluation, hidden-target bound-with-provenance (behavior Q), deterministic authored-order preservation and pure-function repeatability (behavior M), full three-input immutability (behavior N), case-insensitive runtime-target-name resolution, full provenance carry-through, fail-closed on a structurally invalid reference or candidate artifact, and absence of any source-ownership-style field in the result (`sourceOwner`/`sourceFile`/`component`/`symbol`/`causedBy`).
+
+## Validation results
+
+All commands run from the repository root, after the implementation commit:
+
+- `npm run typecheck` — pass, zero errors.
+- `npm run lint` — pass, zero errors/warnings.
+- `npm test` — 46 test files, 889 tests, all pass.
+- `npm run build` — pass, clean `tsc` compile.
+- `npm run check:docs` — pass (17 required files present, `ROADMAP.md` format intact — no implementation batches added).
+- `git diff --check` — exit 0, no whitespace errors.
+- `npm pack --dry-run` — pass; `dist/domain/externalReferenceRuntimeBinding.{js,d.ts,js.map}` confirmed present in the tarball listing (public exports changed, so this was run per the task's requirement).
+- `npm run test:security` — pass (5 + 63 = 68 tests: `policy.test.ts` + real-Chromium `chromiumAdapter.test.ts`), run because a new public input surface (`ReferenceRuntimeBindingDeclaration`) was added.
+- `npm run test:browser` — pass (9 files, 120 tests, real Chromium), run as full regression confirmation per established repository policy, even though Prompt 5 itself has no Chromium dependency.
+
+## Regression results
+
+- Prompt 1 artifact/lifecycle: unaffected — `externalReference.ts` untouched this prompt.
+- Prompt 2 regions/relationships: unaffected — `externalReferenceRegions.ts`/`externalReferenceRegionRelationships.ts` untouched; `REFERENCE_REGION_ID_PATTERN` only imported, never modified.
+- Prompt 3 requirements/adequacy: unaffected — `externalReferenceRequirements.ts` untouched.
+- Prompt 4 state/compatibility: unaffected — `externalReferenceCompatibility.ts`, `explicitState.ts`, `externalReferenceApplicability.ts` untouched; `evaluateReferenceCandidateCompatibility` called, never modified.
+- v0.2 runtime target identity/resolution: unaffected — `request/request.ts`, `schema.ts`, `browser/evidenceCapture.ts` untouched.
+- v0.4 comparison: unaffected in behavior — `comparisonEngine.ts`'s only change is exporting a previously-private function (`targetPresence`) verbatim; every existing caller and every existing test of `evaluateComparability`/`compareObservations`/`compareTargetConfiguration` continues to pass unchanged.
+- v0.5 contracts: unaffected — no file in `frontendContracts*.ts` touched.
+- v0.6 runtime/static correlation: unaffected — `boundedAgentContext*.ts` untouched; its status vocabulary/discipline was read for precedent only, never imported or modified.
+- Full unit (889/889), browser (120/120), and security (68/68) suites all pass with zero regressions.
+
+## Security impact
+
+- No new external input surface beyond an in-memory, caller-supplied declaration array (no file, no CLI flag, no network call in this prompt) — the smallest possible surface, since no CLI/config-file loader was added.
+- `evaluateReferenceRuntimeBindings` performs no filesystem access, no network access, and no browser/Chromium invocation of any kind.
+- `test:security` (policy + real-Chromium adapter tests) re-run and passing, confirming no regression to the existing safety/navigation policy surface (untouched by this prompt).
+
+## Documentation changes
+
+- `docs/CONTRACTS.md` — new "v0.7 Prompt 5 explicit reference-region ↔ runtime-target binding" section (full type shapes, key rules, status-mapping table equivalent in prose, hidden-target/duplicate/multiple-regions decisions, persistence/identity decisions, CLI-surface decision).
+- `docs/ARCHITECTURE.md` — new paragraph in the "Planned v0.7–v0.10" section describing the Prompt 5 module addition, its reuse of Prompt 4's compatibility gate and v0.4's `targetPresence`, and its architectural-discipline-only (not vocabulary) reuse of v0.6's uncertainty handling.
+- `docs/WORKFLOWS.md` — "Current external-reference foundation workflow" retitled to "Prompts 1-5" and extended with a paragraph describing `evaluateReferenceRuntimeBindings`.
+- `docs/COMMANDS.md` — not touched (no CLI surface change this prompt).
+
+## Tooling incidents
+
+None. No orchestrator was invoked (direct-implementation mode used throughout, consistent with Prompts 2–5); no background/speculative subagent writes occurred; the Prompt 1 stray-fork-writes stash remains untouched, unapplied, and unmined as precedent.
+
+## Out-of-scope confirmation
+
+This prompt implements no automatic target matching, no computer vision, no screenshot segmentation, no OCR, no fuzzy matching, no geometry-based matching, no source-correlation changes, no source ownership, no reference/candidate geometry delta, no spacing delta, no relationship fidelity evaluation, no selected-requirement evaluation, no fidelity PASS/FAIL, no style fidelity, no image similarity, no bounded correction packet, no coding-agent context changes or invocation, no source edits, no correction loop, no viewer, and no annotation. `evaluateReferenceRuntimeBindings` reads only `reference.regions` (for structural validation), `reference.applicability` (via the reused compatibility gate), and `candidate.requestConfig.targets`/`candidate.targetEvidence` — it never reads `reference.requirements`, never compares geometry, and never touches source code or my-dev-kit retrieval of any kind.
+
+## Known limitations
+
+- A binding declaration supports exactly one `runtimeTarget` per `referenceRegion` — there is no "candidate alternatives" mechanism (deliberately; the task's own guidance treats this as the smallest, cleanest representation, and any future need for ranked/multiple candidate targets per region is left to a later prompt to design explicitly, not improvised here).
+- No CLI/config-file surface exists yet for authoring binding declarations outside of direct programmatic use — deferred to Prompt 6 per the task's own guidance.
+- `targetVisible` provenance is populated only when the underlying `TargetVisibility` evidence is itself available; a `bound` result for a target whose visibility evidence is unavailable simply omits the field rather than guessing a value.
+
+## Remaining risks
+
+- None identified that block this prompt's own scope. The primary forward consideration for Prompt 6 (structured fidelity evaluation) is how it will consume `ReferenceRuntimeBindingEvaluation.bindings` together with Prompt 3's per-requirement expectations to determine which selected requirements have sufficient bound evidence for evaluation — flagged for that prompt's own precedent review, not preempted here.
+
+## Exact next action
+
+v0.7 Prompt 6 — structured reference-vs-candidate fidelity evaluation.