@dailephd/my-frontend-observer 0.9.1 → 0.10.1

package/docs/reports/v0.8-bounded-context-correlation-batch7.md

@@ -1,233 +1,233 @@
-# v0.8 Batch 7 — Bounded Agent Context, Correlation, Provenance, and Raw Evidence Navigation — Implementation Report
-
-## 1. Starting state
-
-- Branch: `master`
-- Starting HEAD: `b9eaa743b4db3e2fbfeb3503ea002cadeedf79b9` ("feat: add v0.8 binding fidelity interaction and view controls", Batch 6)
-- `origin/master` after `git fetch`: `a1de8ac01e1367b60021cb04226f56369fa2debb`
-- `git rev-list --left-right --count origin/master...HEAD`: `0  6`
-- `git merge-base --is-ancestor origin/master HEAD` → succeeded: strict ancestor, no divergence. No pull/rebase/merge/reset performed.
-- Starting `git status --short`: clean.
-- Package version confirmed `0.7.0` throughout; never bumped.
-
-## 2. Same recurring path contradiction, resolved the same way
-
-Task §6 repeated the identical `Join-Path`-vs-restated-sentence contradiction present in every prior batch since Batch 4. Re-ran the literal algorithm and confirmed the containment assertion passes only for the inside-repository path:
-
-```
-REPO_ROOT=Z:\Users\newuser\Projects\my-frontend-observer
-WORKFLOW_ROOT=Z:\Users\newuser\Projects\my-frontend-observer\.my-dev-kit-workflow\v0.8\batch-07
-ContainmentCheck=True
-```
-
-Used **`Z:\Users\newuser\Projects\my-frontend-observer\.my-dev-kit-workflow\v0.8\batch-07`**, per the same established precedent.
-
-## 3. Prior workflow-root audit
-
-Sibling `...my-frontend-observer.my-dev-kit-workflow\v0.8\` holds only `batch-01/02/03` (untouched). Inside-repo `.my-dev-kit-workflow\v0.8\` held `batch-04/05/06` (untouched) before this batch added `batch-07` alongside them.
-
-## 4. Predecessor reports/plan and my-dev-kit retrieval
-
-All six predecessor reports read in full. `docs/plans/v0.8-implementation-plan.md`'s Batch 7 section matches the task's scope exactly. All required source files (§4 items 17-35) read in full, including `boundedAgentContext.ts`, `boundedAgentContextProjection.ts`, `boundedAgentContextCorrelation.ts`, `referenceFidelityProjection.ts`, and the existing viewer server (`classify.ts`, `linkedEvidence.ts`, `comparisonView.ts`, `evaluationView.ts`, `referenceView.ts`). My-dev-kit index rebuilt at `$WORKFLOW_ROOT\my-dev-kit-index`; all nine required searches run and cross-checked directly against the source - every result matched.
-
-## 5. Context persistence-boundary audit (task §11)
-
-Confirmed via `src/viewerServer/evidence/classify.ts`'s own existing comment: `my-frontend-observer/bounded-agent-context` is explicitly the "known-but-unreadered" kind - no disk writer/reader/manifest contract exists for it as an Observer evidence-root artifact family, and this batch adds **none**. No `writeBoundedAgentContextArtifact`, no bounded-context writer, no bounded-context artifact directory, no `save-context` command exists anywhere in the diff (grep-verified). Bounded agent context is consumed exclusively as explicit, ephemeral viewer-session operational input via `--context-file`.
-
-## 6. Context-file architecture (task §12-§15)
-
-The context file's root **is** one `BoundedAgentContextArtifact` value directly - no `{"context": {...}}` wrapper (task §12's explicit requirement). `src/cli.ts#loadContextFile` (new) mirrors `loadBindingsFile`'s exact shape: `statSync` size check (bounded by `MAX_CONTEXT_FILE_BYTES`, §7 below) before ever reading bytes, then `readFileSync`+`JSON.parse`, then delegates classification to `src/viewerServer/context.ts#classifyContextFileContent` (new). The loader never derives context, never correlates anything, never mutates the parsed value, and never normalizes it into a different shape - it either passes the exact parsed object through (after validation) or fails closed with a specific error.
-
-## 7. File-size bound (task §15)
-
-Reuses the existing Batch 2 `MAX_MANIFEST_CANDIDATE_BYTES` value (2,000,000 bytes), re-exported from `src/viewerServer/context.ts` as `MAX_CONTEXT_FILE_BYTES`, rather than inventing a second bound - documented rationale: a `BoundedAgentContextArtifact`'s own frozen numeric caps (`MAX_RUNTIME_TARGETS=25`, `MAX_CORRELATION_RECORDS=25`, `MAX_STATIC_CANDIDATES_PER_TARGET=5`, `MAX_FIDELITY_MISMATCHES=15`, etc. - all in `src/domain/boundedAgentContext.ts`) already make a genuine context artifact far smaller than 2MB in any realistic case, so the same "generous headroom, never an arbitrarily large read" rationale Batch 2 established applies unchanged.
-
-## 8. Canonical validator reuse (task §67)
-
-`classifyContextFileContent` calls the existing `isValidBoundedAgentContextArtifact` exactly once for a current-schema candidate - grep-verified as the only call site of that validator in the diff, and no second/duplicated validation logic exists anywhere. `classifyContextFileContent` itself only inspects `artifactKind`/`schemaVersion` (the wrapper-level routing decision) before delegating full structural validation to the existing function.
-
-## 9. Unsupported-version behavior (task §16)
-
-A recognized `artifactKind` with a `schemaVersion` other than the current `'1.0.0'` produces `{status: 'unsupported-version', foundSchemaVersion}` - **not** a startup failure (task §16's explicit requirement) - the viewer still starts, and `ContextWorkspace.tsx` shows this state honestly, never projecting any current-shape UI onto it. Proven at three levels: unit (`contextViewerServer.test.ts`), CLI dispatch (`cliViewDispatch.test.ts`), and CLI-syntax (`cliView.test.ts` confirms a *malformed* current-schema file still fails, distinct from this case).
-
-## 10. Malformed-context startup failure (task §17)
-
-Unreadable file, invalid JSON, a non-object root, the wrong `artifactKind`, or a structurally invalid *current*-schema artifact all fail viewer startup clearly (nonzero exit, no server started) - covered by five dedicated `cliView.test.ts` tests, each asserting the specific error text.
-
-## 11. Context session lifetime (task §13)
-
-`ViewerServerState.context: ContextSessionState` (default `{status: 'none'}`) is set exactly once at `startViewer` call time and never re-read, never re-parsed, never mutated for the life of the process. The supplied file's path is never returned by `GET /api/context`, never logged to the browser, and is not part of `contextId`/`contextRequestId`/any viewer evidence identity (grep-verified: the path string exists only inside `runViewCommand`'s local scope in `src/cli.ts`).
-
-## 12. Exact source resolution (task §24, §69)
-
-`src/viewerServer/evidence/contextSourceView.ts#resolveContextSources` (new) resolves every field of `BoundedAgentContextSourceReferences` by exact canonical identity only, reusing Batch 4's `linkedEvidence.ts` module extended with three additive resolvers:
-
-- `resolveObservationById(root, observationId)` - bare `observationId` exact match (the only identity a context's `sources.observationIds` entries actually carry - distinct from Batch 4/5's compound `{observationId, requestId, producer, observationSchemaVersion}` cross-artifact reference).
-- `resolveEvaluationByIdentity(root, evaluationId, evaluationRequestId)`.
-- `resolveReferenceByIdentity(root, referenceId, referenceRequestId)` (matches either the `external-reference-imported` or `external-reference-approved` family).
-
-`resolveComparisonByIdentity`/`resolveBaselineContractById`/`resolveChangeContractById` (existing, unchanged) cover the remaining fields. Every resolver preserves the exact missing/ambiguous discipline already established: zero matches → `missing`, two or more → `ambiguous` (never silently picked). No pathname/name/similarity heuristic exists anywhere in this module.
-
-## 13. Raw evidence navigation (task §26-28, §60-61, §70)
-
-`viewer/src/components/RawEvidenceViewer.tsx` (new) reuses the existing Batch 2 `useArtifactDetail`/`GET /api/artifacts/<handle>` unchanged - no second full-artifact retrieval mechanism, no local filesystem read, no editable view, no arbitrary path/URL input field anywhere (verified in real Chromium, Case H: zero `input[type="file"]`/`input[type="url"]` elements exist on the page). `EvidenceReference.path` values are rendered only as plain provenance text (`ContextWorkspace.tsx`'s correlation/omission/truncation sections) - grep-verified: never passed to `fs.readFile`/`path.resolve`/any static file server anywhere in the diff.
-
-## 14. Runtime target projection display (task §29, §42)
-
-`BoundedRuntimeTargetProjection`'s optional fields (`geometry`/`visibility`/`overflow`/`scrollOwner`/`relationshipEvidence`/`screenshotRef`) each render "not included in this bounded context" when absent - never a fabricated `false`/`0`/empty-but-present value (`ContextWorkspace.tsx`'s target list rendering).
-
-## 15. Adequacy / adequacy reasons (task §31-33, §71)
-
-`Adequacy.state` (`adequate`/`partial`/`inadequate`) is rendered verbatim via a colored badge, never collapsed to a boolean; every `AdequacyReason.code`/`.detail` is listed exactly. The canonical reason-code vocabulary (`ADEQUACY_REASON_CODES`) is displayed as-is - no viewer-invented stronger claim exists.
-
-## 16. Omissions / truncations / required-evidence-loss prominence (task §33-35, §72-73)
-
-`OmissionRecord`/`TruncationRecord` are rendered in two visually distinct groups each (required vs. optional), with `required: true` records placed in a dedicated `.context-required-loss` block (red border/background, `role="alert"`) - proven visible without reading raw JSON in real Chromium (Case D). Omissions and truncations are never conflated with each other - separate sections, separate fields (`reason`/`detail` for omissions; `limit`/`actualCount` for truncations).
-
-## 17. Correlation-absent vs. correlation statuses (task §36-40, §74-77)
-
-`artifact.correlations === undefined` renders "Static correlation not included in this context." - never "unavailable" (task §36's explicit distinction, proven in Case E). When present, `correlated`/`ambiguous`/`unavailable` are preserved exactly per record: `correlated` shows its one candidate labeled "Correlated candidate" (never "Owner"); `ambiguous` shows **every** supplied candidate with copy explicitly stating none is chosen over another (proven in Case B: both candidate ids visible, and the response body contains neither "owner" nor "winner" as a UI claim); `unavailable` shows zero candidates and the literal text "No static candidate available for this correlation" (proven in Case C). All UI text was audited (task §63) - no unqualified "Owner"/"Source owner"/"Owned by"/"Responsible component" string exists anywhere in `ContextWorkspace.tsx`.
-
-## 18. Static producer / candidates / evidence basis / correlation-level provenance (task §41-46, §78-80)
-
-`StaticEvidenceProducerIdentity.name`/`.version`/`.indexId` are displayed exactly as supplied - never derived from a local path/timestamp/session (grep-verified: no such derivation exists). `StaticCandidateReference.candidateId`/`.kind`/`.evidenceRefs.length` are shown verbatim; the `candidateId` string is never used as an `href`, `fs` argument, or otherwise converted into a filesystem path (proven in Case J: zero anchors with `href` containing `symbol:`/`file:` inside the context workspace). `evidenceBasis`, record-local `omissions`/`truncations` (kept visually separate from top-level ones, with their own `required` visibility), and `provenance.correlatedAt` are all rendered exactly as supplied.
-
-## 19. No runtime rebuild / no runtime derivation / no my-dev-kit execution (task §18-21, §61-63, §96)
-
-Grep-verified across the entire diff (`src/viewerServer/`, `viewer/src/`):
-
-- `projectBoundedAgentContext(` — **zero** occurrences.
-- `deriveRuntimeStaticCorrelations(` — **zero** occurrences.
-- `attachRuntimeStaticCorrelations(` — **zero** occurrences.
-- `npx @dailephd/my-dev-kit` / `child_process` spawning of my-dev-kit — **zero** occurrences (the only `child_process` import in the shipped viewer server is the pre-existing, unrelated Batch 1 `openBrowser.ts` best-effort browser-launch helper).
-
-All four canonical functions are used **only** inside `tests/support/evidenceFixtures.ts` (test/fixture generation, explicitly sanctioned by task §64) to build trustworthy positive context fixtures - never inside `src/viewerServer/` or `viewer/src/`.
-
-## 20. Bounded reference-fidelity projection (task §48-52, §82-85)
-
-`artifact.fidelity === undefined` renders "Reference fidelity not included in this bounded context." - never implied as passing (proven in server-level unit tests and, implicitly, by every non-fidelity real-browser case never showing a PASS/FAIL banner). When present: identity fields (`referenceId`/`referenceRequestId`/`candidateObservationId`/`candidateRequestId`/`adequacy`/`compatibility`) are shown exactly; `state`/`blockedBy` render prominently (a `not-evaluated` blocked projection never displays an empty `mismatches` list as "no problems" - it shows an explicit "Evaluation was blocked..." note instead, proven in Case G); `mismatches` and `protectedContext` render in fully separate sections, each item preserving every canonical field (`requirementId`/`category`/`status`/`reasonCode`/`detail`/numeric or relationship fields) with no recomputation (grep-verified: `evaluateReferenceCandidateFidelity` is never called for the *bounded projection* rendering path itself - only reused, unchanged, for the separate live-evaluation panel below it).
-
-## 21. Historical vs. live fidelity independence (task §53-54, §86)
-
-When the context's `referenceId`/`candidateObservationId` exactly resolve within the current evidence root, `ContextWorkspace.tsx` embeds the existing, **unmodified** Batch 6 `ReferenceFidelityPanel` component directly beneath the bounded projection - the exact same on-demand `evaluateReferenceCandidateFidelity` trigger Batch 6 already built, reused verbatim (no duplicated fidelity-rendering logic). The two are labeled distinctly ("Bounded context fidelity projection" vs. "Current on-demand fidelity evaluation") with an explicit note that re-running never silently replaces the bounded projection. Proven in real Chromium (Case F): clicking "Evaluate Fidelity" produces a *second*, independently-rendered PASS state while the bounded projection's own PASS banner remains unchanged and still visible.
-
-## 22. Context-target ↔ runtime-target interaction (task §30, §47, §81)
-
-Selecting a bounded context target or a correlation record uses only exact `targetId`/`runtimeTargetId` string equality (`ContextWorkspace.tsx`). For a selected target, `SourceObservationTargetCheck` checks membership in each *exactly resolved* source observation's own already-fetched `targetEvidence` (a plain lookup over already-loaded JSON via the existing `useArtifactDetail`, never a new derivation) and lists **every** matching source observation rather than picking one when more than one contains the same target id - satisfying task §30's explicit "never guess which source observation owns the target" requirement.
-
-## 23. API changes (task §55-57, §97)
-
-| Route | Method | Semantics |
-|---|---|---|
-| `GET /api/context` | GET/HEAD | `{ok:true, status:'none'}` \| `{ok:true, status:'unsupported-version', foundSchemaVersion}` \| `{ok:true, status:'valid', artifact, sourceResolution}`. `405` for any write method (enforced globally by the existing request handler, before route dispatch). |
-
-No write endpoint was added (`POST/PUT /api/context`, `POST /api/correlation`, `POST /api/source`, `GET /api/file?path=...` all confirmed absent). Every other route (`/api/status`, `/api/index`, `/api/artifacts/<handle>`, `/api/media/<handle>/<role>`, `/api/observations/<handle>/relationships`, `/api/comparisons/<handle>/view`, `/api/evaluations/<handle>/view`, `/api/references/...`) is byte-for-byte unchanged.
-
-## 24. PWA cache boundary (task §98)
-
-**PASS.** `GET /api/context` lives under `/api/`, already covered by Batch 1's `navigateFallbackDenylist`. `tests/unit/viewerPwaBuild.test.ts` gained an explicit Batch 7 assertion against the real built `sw.js`: still exactly one `registerRoute` call, no `/api/context` precache entry. Independently confirmed against the real built server in the smoke test (§28).
-
-## 25. Files created
-
-- `src/viewerServer/context.ts`
-- `src/viewerServer/evidence/contextSourceView.ts`
-- `viewer/src/components/ContextWorkspace.tsx`, `RawEvidenceViewer.tsx`
-- `viewer/src/hooks/useBoundedContext.ts`
-- `viewer/src/types/context.ts`
-- `tests/unit/contextViewerServer.test.ts`
-- `tests/browser/boundedContextWorkspace.test.ts`
-- `docs/reports/v0.8-bounded-context-correlation-batch7.md` (this file)
-
-## 26. Files modified
-
-- `src/cli.ts` - `view --context-file` (§6-10).
-- `src/viewerServer/evidence/linkedEvidence.ts` - three additive resolvers (§12); every existing function unchanged.
-- `src/viewerServer/httpServer.ts` - one new route (§23); `ViewerServerState.context` field added.
-- `src/viewerServer/viewerService.ts` - `StartViewerOptions.context` added, threaded into `ViewerServerState`.
-- `tests/support/evidenceFixtures.ts` - `writeBoundedContextEvidenceFixture` added (real evidence + real canonical context/correlation/fidelity fixtures for every required test case, §27).
-- `tests/unit/cliView.test.ts`, `tests/unit/cliViewDispatch.test.ts` - `--context-file` startup/dispatch tests added (§66).
-- `tests/unit/viewerPwaBuild.test.ts` - Batch 7 cache-boundary assertion added.
-- `viewer/src/App.tsx` - added a "Bounded context" / "Evidence" mode toggle in the header; the context mode renders `ContextWorkspace` in place of the normal evidence body; a `navigateToRecord` callback lets context-mode source navigation switch back to evidence mode with the resolved record selected (task §25).
-- `viewer/src/styles/index.css` - additive Batch 7 rules.
-- `docs/ARCHITECTURE.md`, `docs/COMMANDS.md` - new/updated Batch 7 sections.
-
-## 27. Test fixture generation methodology (task §64-65)
-
-`writeBoundedContextEvidenceFixture` builds real Observer evidence (before/after observations, comparison, baseline/per-change contract, contract evaluation with a genuine `overallVerdict: "FAIL"`, an approved external reference) entirely through the existing canonical writers/application services, then builds every positive `BoundedAgentContextArtifact` variant by calling the real `projectBoundedAgentContext` (reading back the real persisted evaluation/reference artifacts through their existing canonical readers first, never re-derived by hand) and, where correlation is needed, the real `deriveRuntimeStaticCorrelations`/`attachRuntimeStaticCorrelations` - never hand-authored. Only the deliberately negative/malformed fixtures in `cliView.test.ts` (wrong kind, invalid JSON, structurally invalid current schema, non-object root) are hand-authored, exactly as task §64 permits.
-
-An early version of this fixture accidentally made the "adequate correlated" case genuinely `partial` (the same baseline used for the required-truncation demonstration was shared with the main pipeline). This was caught by a direct assertion in `contextViewerServer.test.ts` (`expect(fixture.baseContext.adequacy.state).toBe('adequate')` initially failed with `'partial'`), and fixed by giving the required-truncation demonstration its own separate `projectBoundedAgentContext` call with a dedicated 11-clause baseline, never attached to the persisted contract-evaluation pipeline - documented here as the methodology that caught it (verify fixtures against real derived output before writing UI-level assertions against them, per the same discipline established in every prior batch's report).
-
-Required fixture cases (task §65 A-L): **A** (adequate, one correlated target) - `correlatedContext`; **B** (ambiguous, ≥2 candidates) - `ambiguousContext`; **C** (unavailable) - `unavailableContext`; **D** (required omission) - `requiredOmissionContext`; **E** (required truncation) - `requiredTruncationContext`; **F** (no `correlations` field) - `baseContext`; **G** (fidelity mismatches) - `fidelityMismatchContext`; **H** (protectedContext) - `baseContext` (protected/preserved context present alongside a PASS state); **I** (fidelity `not-evaluated`/`blockedBy`) - `blockedFidelityContext`; **J** (missing linked source) - any context + deleting the observation directory in the test itself (mirrors the established Batch 4 pattern); **K** (multiple source observations relevant to the same target) - not built as a dedicated fixture this batch (task §65 K is explicitly "where useful"; the two-source-observation membership-check code path is exercised structurally by `SourceObservationTargetCheck`'s "list every match" implementation, but not proven with a real two-observations-sharing-a-target Chromium fixture - recorded as a residual gap, §31); **L** (unsupported future schema) - hand-authored negative fixture in `cliView.test.ts`/`cliViewDispatch.test.ts`.
-
-## 28. Validation results
-
-| Command | Result |
-|---|---|
-| `npm run typecheck` | **PASS** |
-| `npm run lint` | **PASS** |
-| `npm test` (`vitest run`) | **PASS** — 1156/1156 tests, 63/63 files |
-| `npm run build` | **PASS** |
-| `npm run check:docs` | **PASS** — 17 required files |
-| `npm run test:browser` | **PASS** — 168/168 tests, 17/17 files (one transient resource-contention flake on a single unrelated pre-existing Batch 6 test during a backgrounded run was reproduced as passing cleanly in isolation and on a subsequent full fresh run - not a Batch 7 regression, see §29) |
-| `git diff --check` | **PASS** — no whitespace errors |
-
-## 29. A note on browser-test flakiness during this batch's validation
-
-One `npm run test:browser` invocation, run in the background while many Chrome processes were already active on the machine, reported 19 failed tests across 11 files - all in pre-existing v0.1-v0.3-era suites (e.g. `windowScrollScenario.test.ts`) this batch never touched, all failing with a 30s timeout, and the run itself took ~8x longer than normal (394s vs. ~50-115s). This is a resource-contention symptom, not a functional regression: the exact same failing test file was re-run in isolation immediately afterward and passed cleanly, and a subsequent full fresh `npm run test:browser` run passed all 168/168 tests. No source change was made in response to this - it was correctly diagnosed as environmental, not a defect.
-
-## 30. Built viewer smoke
-
-Fixture: real before/after observations, comparison, contract evaluation (genuine `overallVerdict: "FAIL"`), approved reference (genuine fidelity PASS), and a real `BoundedAgentContextArtifact` (adequate, one `correlated` target, fidelity `pass`) built via `.my-dev-kit-workflow\v0.8\batch-07\tmp\build-smoke-context.mjs` (not committed) against the compiled `dist/*.js`, written to `.my-dev-kit-workflow\v0.8\batch-07\contexts\smoke-context.json`.
-
-Command: `node dist/cli.js view --root "<root>" --context-file "<context.json>" --bindings-file "<bindings.json>" --port 4319 --no-open`
-
-All required checks passed against the real running built server: `/api/status` → `200`; `/api/index` → 8 real records; `/api/context` → `status:"valid"`, `adequacy:"adequate"`, `correlations[0].status:"correlated"`, `fidelity.state:"pass"`, and every `sourceResolution` field `resolved` (2 observations, comparison, evaluation, reference); write method → `405`; PWA shell → `200`; `sw.js` contains zero `api/context` occurrences; the coexisting live fidelity endpoint (`--bindings-file` also supplied) independently returns a real `state:"pass"` for the same reference/candidate, proving `--bindings-file`/`--context-file` coexistence; a directory-traversal probe against `/api/artifacts/<handle>` returned `404` (no filesystem escape); the evidence root contained exactly the 10 expected real fixture files with no stray writes; the context JSON file's checksum was confirmed unchanged after the server session; `netstat` confirmed `127.0.0.1:4319` only; the server was located by its real PID and terminated with `taskkill /F`; a follow-up `netstat` confirmed the port was released.
-
-**Result: PASS.**
-
-## 31. Generated path inventory
-
-| Path | Disposition |
-|---|---|
-| `WORKFLOW_ROOT\tmp\build-smoke-context.mjs` | Retained (dev tooling, not committed) |
-| `WORKFLOW_ROOT\contexts\smoke-context.json` | Retained (dev tooling, not committed) |
-| `WORKFLOW_ROOT\bindings\smoke-bindings.json` | Retained (dev tooling, not committed) |
-| `WORKFLOW_ROOT\smoke\evidence-root` | Retained - 10 real fixture files verified |
-| `WORKFLOW_ROOT\logs\*` | Retained (smoke evidence) |
-| `WORKFLOW_ROOT\my-dev-kit-index\*` | Retained |
-| `WORKFLOW_ROOT\{cache,fixtures}` | Retained, empty/unused |
-| Repo-root `dist/` | Ordinary build output (gitignored) |
-| Sibling `...my-frontend-observer.my-dev-kit-workflow\v0.8\{batch-01,02,03}` | Untouched |
-| Inside-repo `.my-dev-kit-workflow\v0.8\{batch-04,05,06}` | Untouched |
-
-## 32. Repository pollution check
-
-**PASS.** `git status --short` before staging showed exactly the 10 modified + 8 new Batch-7-owned paths listed in §25/§26. No unexpected file/directory anywhere in the repository or its parent. No malformed sibling Batch 7 workflow path exists.
-
-## 33. Batch 1-6 regression check
-
-**PASS.** All 168 browser tests across 17 files pass on a clean run, including every Batch 1-6 test file, unmodified except the three additive test-file changes described in §26 (`cliView.test.ts`/`cliViewDispatch.test.ts` for the new `--context-file` flag, `viewerPwaBuild.test.ts` for the new cache-boundary assertion) - no pre-existing assertion was weakened or removed.
-
-## 34. v0.1-v0.7 regression check
-
-**PASS.** Full unit suite (1156/1156) green; `src/domain/boundedAgentContext*.ts` and every existing reader/service are byte-for-byte unchanged except the two additive exports already documented in Batch 6 (`deriveCoordinateScale`) - Batch 7 touches zero files under `src/domain/`.
-
-## 35. Deviations
-
-- The same recurring `$WORKFLOW_ROOT` path-instruction contradiction as every prior batch since Batch 4, resolved identically (§2).
-- No other deviation from the task's literal text.
-
-## 36. Remaining uncovered risks
-
-- **Task §65 Case K (multiple source observations relevant to the same target) has no dedicated real-browser fixture/test** this batch, though the implementing code (`SourceObservationTargetCheck`, §22) structurally lists every match rather than picking one, by construction - a real-browser proof for this specific case is a reasonable follow-up.
-- **`resolveContextSources` performs up to six independent bounded evidence-tree walks per `/api/context` request** (one per source-reference kind, run in parallel) - the same per-request-recomputation-cost category already noted as a residual risk in the Batch 4/5/6 reports for linked-evidence resolution generally. Not a correctness risk.
-- **The context/evidence mode toggle in `App.tsx` is a simple two-state switch, not integrated with the URL/history** - navigating away and back within a session loses the "which mode was active" state on a full page reload (not persisted, by design - session-only). A minor UX limitation, not a correctness concern.
-- Batches 1-6's previously reported risks (install-prompt "available" branch untested in headless Chromium, no live service-worker execution test, per-request linked-evidence walk cost, lock's zoom-multiplier mirroring simplification) remain unresolved and out of this batch's scope.
-
-## 37. Out-of-scope confirmation
-
-Confirmed absent from this batch's diff: bounded-agent-context persistence/writer, running my-dev-kit from the viewer, inventing static/source ownership, rebuilding bounded-agent-context at runtime, rebuilding runtime/static correlation at runtime, arbitrary filesystem browsing, source-code file browsing, raw evidence editing, annotation, source editing, automatic correction, cloud hosting, database, authentication, collaboration.
-
-## 38. Final verdict
-
-Batch 7 ("Bounded agent context, correlation, provenance, and raw evidence navigation") is implemented and independently validated: a developer can launch `view --context-file` with one explicit, validated `BoundedAgentContextArtifact`, inspect its identity/profile/adequacy/reasons, every bounded runtime target's included-or-honestly-absent fields, required-vs-optional omissions and truncations with required loss made visually unmistakable, runtime/static correlation exactly as `correlated`/`ambiguous`/`unavailable` (or honestly "not included" when the field itself is absent) with every ambiguous candidate shown and none promoted as a winner, static producer/candidate identities displayed verbatim and never treated as filesystem paths or edit authorization, and a bounded reference-fidelity projection (mismatches, protected context, blocked state) displayed alongside - never merged into - a separately-triggered live Batch 6 fidelity evaluation reusing that exact unmodified component - while every exactly-resolved Observer source reference safely navigates to its existing Batch 2/3/4/5 raw-evidence and visual-workspace surfaces, entirely within the authorized evidence root. The viewer never runs my-dev-kit, never calls `projectBoundedAgentContext`, and never calls `deriveRuntimeStaticCorrelations`/`attachRuntimeStaticCorrelations` at runtime (all three grep-confirmed). No Batch 8 release/integrated-hardening work was pulled forward, and no release/publication action was taken. Package version remains `0.7.0`.
+# v0.8 Batch 7 — Bounded Agent Context, Correlation, Provenance, and Raw Evidence Navigation — Implementation Report
+
+## 1. Starting state
+
+- Branch: `master`
+- Starting HEAD: `b9eaa743b4db3e2fbfeb3503ea002cadeedf79b9` ("feat: add v0.8 binding fidelity interaction and view controls", Batch 6)
+- `origin/master` after `git fetch`: `a1de8ac01e1367b60021cb04226f56369fa2debb`
+- `git rev-list --left-right --count origin/master...HEAD`: `0  6`
+- `git merge-base --is-ancestor origin/master HEAD` → succeeded: strict ancestor, no divergence. No pull/rebase/merge/reset performed.
+- Starting `git status --short`: clean.
+- Package version confirmed `0.7.0` throughout; never bumped.
+
+## 2. Same recurring path contradiction, resolved the same way
+
+Task §6 repeated the identical `Join-Path`-vs-restated-sentence contradiction present in every prior batch since Batch 4. Re-ran the literal algorithm and confirmed the containment assertion passes only for the inside-repository path:
+
+```
+REPO_ROOT=Z:\Users\newuser\Projects\my-frontend-observer
+WORKFLOW_ROOT=Z:\Users\newuser\Projects\my-frontend-observer\.my-dev-kit-workflow\v0.8\batch-07
+ContainmentCheck=True
+```
+
+Used **`Z:\Users\newuser\Projects\my-frontend-observer\.my-dev-kit-workflow\v0.8\batch-07`**, per the same established precedent.
+
+## 3. Prior workflow-root audit
+
+Sibling `...my-frontend-observer.my-dev-kit-workflow\v0.8\` holds only `batch-01/02/03` (untouched). Inside-repo `.my-dev-kit-workflow\v0.8\` held `batch-04/05/06` (untouched) before this batch added `batch-07` alongside them.
+
+## 4. Predecessor reports/plan and my-dev-kit retrieval
+
+All six predecessor reports read in full. `docs/plans/v0.8-implementation-plan.md`'s Batch 7 section matches the task's scope exactly. All required source files (§4 items 17-35) read in full, including `boundedAgentContext.ts`, `boundedAgentContextProjection.ts`, `boundedAgentContextCorrelation.ts`, `referenceFidelityProjection.ts`, and the existing viewer server (`classify.ts`, `linkedEvidence.ts`, `comparisonView.ts`, `evaluationView.ts`, `referenceView.ts`). My-dev-kit index rebuilt at `$WORKFLOW_ROOT\my-dev-kit-index`; all nine required searches run and cross-checked directly against the source - every result matched.
+
+## 5. Context persistence-boundary audit (task §11)
+
+Confirmed via `src/viewerServer/evidence/classify.ts`'s own existing comment: `my-frontend-observer/bounded-agent-context` is explicitly the "known-but-unreadered" kind - no disk writer/reader/manifest contract exists for it as an Observer evidence-root artifact family, and this batch adds **none**. No `writeBoundedAgentContextArtifact`, no bounded-context writer, no bounded-context artifact directory, no `save-context` command exists anywhere in the diff (grep-verified). Bounded agent context is consumed exclusively as explicit, ephemeral viewer-session operational input via `--context-file`.
+
+## 6. Context-file architecture (task §12-§15)
+
+The context file's root **is** one `BoundedAgentContextArtifact` value directly - no `{"context": {...}}` wrapper (task §12's explicit requirement). `src/cli.ts#loadContextFile` (new) mirrors `loadBindingsFile`'s exact shape: `statSync` size check (bounded by `MAX_CONTEXT_FILE_BYTES`, §7 below) before ever reading bytes, then `readFileSync`+`JSON.parse`, then delegates classification to `src/viewerServer/context.ts#classifyContextFileContent` (new). The loader never derives context, never correlates anything, never mutates the parsed value, and never normalizes it into a different shape - it either passes the exact parsed object through (after validation) or fails closed with a specific error.
+
+## 7. File-size bound (task §15)
+
+Reuses the existing Batch 2 `MAX_MANIFEST_CANDIDATE_BYTES` value (2,000,000 bytes), re-exported from `src/viewerServer/context.ts` as `MAX_CONTEXT_FILE_BYTES`, rather than inventing a second bound - documented rationale: a `BoundedAgentContextArtifact`'s own frozen numeric caps (`MAX_RUNTIME_TARGETS=25`, `MAX_CORRELATION_RECORDS=25`, `MAX_STATIC_CANDIDATES_PER_TARGET=5`, `MAX_FIDELITY_MISMATCHES=15`, etc. - all in `src/domain/boundedAgentContext.ts`) already make a genuine context artifact far smaller than 2MB in any realistic case, so the same "generous headroom, never an arbitrarily large read" rationale Batch 2 established applies unchanged.
+
+## 8. Canonical validator reuse (task §67)
+
+`classifyContextFileContent` calls the existing `isValidBoundedAgentContextArtifact` exactly once for a current-schema candidate - grep-verified as the only call site of that validator in the diff, and no second/duplicated validation logic exists anywhere. `classifyContextFileContent` itself only inspects `artifactKind`/`schemaVersion` (the wrapper-level routing decision) before delegating full structural validation to the existing function.
+
+## 9. Unsupported-version behavior (task §16)
+
+A recognized `artifactKind` with a `schemaVersion` other than the current `'1.0.0'` produces `{status: 'unsupported-version', foundSchemaVersion}` - **not** a startup failure (task §16's explicit requirement) - the viewer still starts, and `ContextWorkspace.tsx` shows this state honestly, never projecting any current-shape UI onto it. Proven at three levels: unit (`contextViewerServer.test.ts`), CLI dispatch (`cliViewDispatch.test.ts`), and CLI-syntax (`cliView.test.ts` confirms a *malformed* current-schema file still fails, distinct from this case).
+
+## 10. Malformed-context startup failure (task §17)
+
+Unreadable file, invalid JSON, a non-object root, the wrong `artifactKind`, or a structurally invalid *current*-schema artifact all fail viewer startup clearly (nonzero exit, no server started) - covered by five dedicated `cliView.test.ts` tests, each asserting the specific error text.
+
+## 11. Context session lifetime (task §13)
+
+`ViewerServerState.context: ContextSessionState` (default `{status: 'none'}`) is set exactly once at `startViewer` call time and never re-read, never re-parsed, never mutated for the life of the process. The supplied file's path is never returned by `GET /api/context`, never logged to the browser, and is not part of `contextId`/`contextRequestId`/any viewer evidence identity (grep-verified: the path string exists only inside `runViewCommand`'s local scope in `src/cli.ts`).
+
+## 12. Exact source resolution (task §24, §69)
+
+`src/viewerServer/evidence/contextSourceView.ts#resolveContextSources` (new) resolves every field of `BoundedAgentContextSourceReferences` by exact canonical identity only, reusing Batch 4's `linkedEvidence.ts` module extended with three additive resolvers:
+
+- `resolveObservationById(root, observationId)` - bare `observationId` exact match (the only identity a context's `sources.observationIds` entries actually carry - distinct from Batch 4/5's compound `{observationId, requestId, producer, observationSchemaVersion}` cross-artifact reference).
+- `resolveEvaluationByIdentity(root, evaluationId, evaluationRequestId)`.
+- `resolveReferenceByIdentity(root, referenceId, referenceRequestId)` (matches either the `external-reference-imported` or `external-reference-approved` family).
+
+`resolveComparisonByIdentity`/`resolveBaselineContractById`/`resolveChangeContractById` (existing, unchanged) cover the remaining fields. Every resolver preserves the exact missing/ambiguous discipline already established: zero matches → `missing`, two or more → `ambiguous` (never silently picked). No pathname/name/similarity heuristic exists anywhere in this module.
+
+## 13. Raw evidence navigation (task §26-28, §60-61, §70)
+
+`viewer/src/components/RawEvidenceViewer.tsx` (new) reuses the existing Batch 2 `useArtifactDetail`/`GET /api/artifacts/<handle>` unchanged - no second full-artifact retrieval mechanism, no local filesystem read, no editable view, no arbitrary path/URL input field anywhere (verified in real Chromium, Case H: zero `input[type="file"]`/`input[type="url"]` elements exist on the page). `EvidenceReference.path` values are rendered only as plain provenance text (`ContextWorkspace.tsx`'s correlation/omission/truncation sections) - grep-verified: never passed to `fs.readFile`/`path.resolve`/any static file server anywhere in the diff.
+
+## 14. Runtime target projection display (task §29, §42)
+
+`BoundedRuntimeTargetProjection`'s optional fields (`geometry`/`visibility`/`overflow`/`scrollOwner`/`relationshipEvidence`/`screenshotRef`) each render "not included in this bounded context" when absent - never a fabricated `false`/`0`/empty-but-present value (`ContextWorkspace.tsx`'s target list rendering).
+
+## 15. Adequacy / adequacy reasons (task §31-33, §71)
+
+`Adequacy.state` (`adequate`/`partial`/`inadequate`) is rendered verbatim via a colored badge, never collapsed to a boolean; every `AdequacyReason.code`/`.detail` is listed exactly. The canonical reason-code vocabulary (`ADEQUACY_REASON_CODES`) is displayed as-is - no viewer-invented stronger claim exists.
+
+## 16. Omissions / truncations / required-evidence-loss prominence (task §33-35, §72-73)
+
+`OmissionRecord`/`TruncationRecord` are rendered in two visually distinct groups each (required vs. optional), with `required: true` records placed in a dedicated `.context-required-loss` block (red border/background, `role="alert"`) - proven visible without reading raw JSON in real Chromium (Case D). Omissions and truncations are never conflated with each other - separate sections, separate fields (`reason`/`detail` for omissions; `limit`/`actualCount` for truncations).
+
+## 17. Correlation-absent vs. correlation statuses (task §36-40, §74-77)
+
+`artifact.correlations === undefined` renders "Static correlation not included in this context." - never "unavailable" (task §36's explicit distinction, proven in Case E). When present, `correlated`/`ambiguous`/`unavailable` are preserved exactly per record: `correlated` shows its one candidate labeled "Correlated candidate" (never "Owner"); `ambiguous` shows **every** supplied candidate with copy explicitly stating none is chosen over another (proven in Case B: both candidate ids visible, and the response body contains neither "owner" nor "winner" as a UI claim); `unavailable` shows zero candidates and the literal text "No static candidate available for this correlation" (proven in Case C). All UI text was audited (task §63) - no unqualified "Owner"/"Source owner"/"Owned by"/"Responsible component" string exists anywhere in `ContextWorkspace.tsx`.
+
+## 18. Static producer / candidates / evidence basis / correlation-level provenance (task §41-46, §78-80)
+
+`StaticEvidenceProducerIdentity.name`/`.version`/`.indexId` are displayed exactly as supplied - never derived from a local path/timestamp/session (grep-verified: no such derivation exists). `StaticCandidateReference.candidateId`/`.kind`/`.evidenceRefs.length` are shown verbatim; the `candidateId` string is never used as an `href`, `fs` argument, or otherwise converted into a filesystem path (proven in Case J: zero anchors with `href` containing `symbol:`/`file:` inside the context workspace). `evidenceBasis`, record-local `omissions`/`truncations` (kept visually separate from top-level ones, with their own `required` visibility), and `provenance.correlatedAt` are all rendered exactly as supplied.
+
+## 19. No runtime rebuild / no runtime derivation / no my-dev-kit execution (task §18-21, §61-63, §96)
+
+Grep-verified across the entire diff (`src/viewerServer/`, `viewer/src/`):
+
+- `projectBoundedAgentContext(` — **zero** occurrences.
+- `deriveRuntimeStaticCorrelations(` — **zero** occurrences.
+- `attachRuntimeStaticCorrelations(` — **zero** occurrences.
+- `npx @dailephd/my-dev-kit` / `child_process` spawning of my-dev-kit — **zero** occurrences (the only `child_process` import in the shipped viewer server is the pre-existing, unrelated Batch 1 `openBrowser.ts` best-effort browser-launch helper).
+
+All four canonical functions are used **only** inside `tests/support/evidenceFixtures.ts` (test/fixture generation, explicitly sanctioned by task §64) to build trustworthy positive context fixtures - never inside `src/viewerServer/` or `viewer/src/`.
+
+## 20. Bounded reference-fidelity projection (task §48-52, §82-85)
+
+`artifact.fidelity === undefined` renders "Reference fidelity not included in this bounded context." - never implied as passing (proven in server-level unit tests and, implicitly, by every non-fidelity real-browser case never showing a PASS/FAIL banner). When present: identity fields (`referenceId`/`referenceRequestId`/`candidateObservationId`/`candidateRequestId`/`adequacy`/`compatibility`) are shown exactly; `state`/`blockedBy` render prominently (a `not-evaluated` blocked projection never displays an empty `mismatches` list as "no problems" - it shows an explicit "Evaluation was blocked..." note instead, proven in Case G); `mismatches` and `protectedContext` render in fully separate sections, each item preserving every canonical field (`requirementId`/`category`/`status`/`reasonCode`/`detail`/numeric or relationship fields) with no recomputation (grep-verified: `evaluateReferenceCandidateFidelity` is never called for the *bounded projection* rendering path itself - only reused, unchanged, for the separate live-evaluation panel below it).
+
+## 21. Historical vs. live fidelity independence (task §53-54, §86)
+
+When the context's `referenceId`/`candidateObservationId` exactly resolve within the current evidence root, `ContextWorkspace.tsx` embeds the existing, **unmodified** Batch 6 `ReferenceFidelityPanel` component directly beneath the bounded projection - the exact same on-demand `evaluateReferenceCandidateFidelity` trigger Batch 6 already built, reused verbatim (no duplicated fidelity-rendering logic). The two are labeled distinctly ("Bounded context fidelity projection" vs. "Current on-demand fidelity evaluation") with an explicit note that re-running never silently replaces the bounded projection. Proven in real Chromium (Case F): clicking "Evaluate Fidelity" produces a *second*, independently-rendered PASS state while the bounded projection's own PASS banner remains unchanged and still visible.
+
+## 22. Context-target ↔ runtime-target interaction (task §30, §47, §81)
+
+Selecting a bounded context target or a correlation record uses only exact `targetId`/`runtimeTargetId` string equality (`ContextWorkspace.tsx`). For a selected target, `SourceObservationTargetCheck` checks membership in each *exactly resolved* source observation's own already-fetched `targetEvidence` (a plain lookup over already-loaded JSON via the existing `useArtifactDetail`, never a new derivation) and lists **every** matching source observation rather than picking one when more than one contains the same target id - satisfying task §30's explicit "never guess which source observation owns the target" requirement.
+
+## 23. API changes (task §55-57, §97)
+
+| Route | Method | Semantics |
+|---|---|---|
+| `GET /api/context` | GET/HEAD | `{ok:true, status:'none'}` \| `{ok:true, status:'unsupported-version', foundSchemaVersion}` \| `{ok:true, status:'valid', artifact, sourceResolution}`. `405` for any write method (enforced globally by the existing request handler, before route dispatch). |
+
+No write endpoint was added (`POST/PUT /api/context`, `POST /api/correlation`, `POST /api/source`, `GET /api/file?path=...` all confirmed absent). Every other route (`/api/status`, `/api/index`, `/api/artifacts/<handle>`, `/api/media/<handle>/<role>`, `/api/observations/<handle>/relationships`, `/api/comparisons/<handle>/view`, `/api/evaluations/<handle>/view`, `/api/references/...`) is byte-for-byte unchanged.
+
+## 24. PWA cache boundary (task §98)
+
+**PASS.** `GET /api/context` lives under `/api/`, already covered by Batch 1's `navigateFallbackDenylist`. `tests/unit/viewerPwaBuild.test.ts` gained an explicit Batch 7 assertion against the real built `sw.js`: still exactly one `registerRoute` call, no `/api/context` precache entry. Independently confirmed against the real built server in the smoke test (§28).
+
+## 25. Files created
+
+- `src/viewerServer/context.ts`
+- `src/viewerServer/evidence/contextSourceView.ts`
+- `viewer/src/components/ContextWorkspace.tsx`, `RawEvidenceViewer.tsx`
+- `viewer/src/hooks/useBoundedContext.ts`
+- `viewer/src/types/context.ts`
+- `tests/unit/contextViewerServer.test.ts`
+- `tests/browser/boundedContextWorkspace.test.ts`
+- `docs/reports/v0.8-bounded-context-correlation-batch7.md` (this file)
+
+## 26. Files modified
+
+- `src/cli.ts` - `view --context-file` (§6-10).
+- `src/viewerServer/evidence/linkedEvidence.ts` - three additive resolvers (§12); every existing function unchanged.
+- `src/viewerServer/httpServer.ts` - one new route (§23); `ViewerServerState.context` field added.
+- `src/viewerServer/viewerService.ts` - `StartViewerOptions.context` added, threaded into `ViewerServerState`.
+- `tests/support/evidenceFixtures.ts` - `writeBoundedContextEvidenceFixture` added (real evidence + real canonical context/correlation/fidelity fixtures for every required test case, §27).
+- `tests/unit/cliView.test.ts`, `tests/unit/cliViewDispatch.test.ts` - `--context-file` startup/dispatch tests added (§66).
+- `tests/unit/viewerPwaBuild.test.ts` - Batch 7 cache-boundary assertion added.
+- `viewer/src/App.tsx` - added a "Bounded context" / "Evidence" mode toggle in the header; the context mode renders `ContextWorkspace` in place of the normal evidence body; a `navigateToRecord` callback lets context-mode source navigation switch back to evidence mode with the resolved record selected (task §25).
+- `viewer/src/styles/index.css` - additive Batch 7 rules.
+- `docs/ARCHITECTURE.md`, `docs/COMMANDS.md` - new/updated Batch 7 sections.
+
+## 27. Test fixture generation methodology (task §64-65)
+
+`writeBoundedContextEvidenceFixture` builds real Observer evidence (before/after observations, comparison, baseline/per-change contract, contract evaluation with a genuine `overallVerdict: "FAIL"`, an approved external reference) entirely through the existing canonical writers/application services, then builds every positive `BoundedAgentContextArtifact` variant by calling the real `projectBoundedAgentContext` (reading back the real persisted evaluation/reference artifacts through their existing canonical readers first, never re-derived by hand) and, where correlation is needed, the real `deriveRuntimeStaticCorrelations`/`attachRuntimeStaticCorrelations` - never hand-authored. Only the deliberately negative/malformed fixtures in `cliView.test.ts` (wrong kind, invalid JSON, structurally invalid current schema, non-object root) are hand-authored, exactly as task §64 permits.
+
+An early version of this fixture accidentally made the "adequate correlated" case genuinely `partial` (the same baseline used for the required-truncation demonstration was shared with the main pipeline). This was caught by a direct assertion in `contextViewerServer.test.ts` (`expect(fixture.baseContext.adequacy.state).toBe('adequate')` initially failed with `'partial'`), and fixed by giving the required-truncation demonstration its own separate `projectBoundedAgentContext` call with a dedicated 11-clause baseline, never attached to the persisted contract-evaluation pipeline - documented here as the methodology that caught it (verify fixtures against real derived output before writing UI-level assertions against them, per the same discipline established in every prior batch's report).
+
+Required fixture cases (task §65 A-L): **A** (adequate, one correlated target) - `correlatedContext`; **B** (ambiguous, ≥2 candidates) - `ambiguousContext`; **C** (unavailable) - `unavailableContext`; **D** (required omission) - `requiredOmissionContext`; **E** (required truncation) - `requiredTruncationContext`; **F** (no `correlations` field) - `baseContext`; **G** (fidelity mismatches) - `fidelityMismatchContext`; **H** (protectedContext) - `baseContext` (protected/preserved context present alongside a PASS state); **I** (fidelity `not-evaluated`/`blockedBy`) - `blockedFidelityContext`; **J** (missing linked source) - any context + deleting the observation directory in the test itself (mirrors the established Batch 4 pattern); **K** (multiple source observations relevant to the same target) - not built as a dedicated fixture this batch (task §65 K is explicitly "where useful"; the two-source-observation membership-check code path is exercised structurally by `SourceObservationTargetCheck`'s "list every match" implementation, but not proven with a real two-observations-sharing-a-target Chromium fixture - recorded as a residual gap, §31); **L** (unsupported future schema) - hand-authored negative fixture in `cliView.test.ts`/`cliViewDispatch.test.ts`.
+
+## 28. Validation results
+
+| Command | Result |
+|---|---|
+| `npm run typecheck` | **PASS** |
+| `npm run lint` | **PASS** |
+| `npm test` (`vitest run`) | **PASS** — 1156/1156 tests, 63/63 files |
+| `npm run build` | **PASS** |
+| `npm run check:docs` | **PASS** — 17 required files |
+| `npm run test:browser` | **PASS** — 168/168 tests, 17/17 files (one transient resource-contention flake on a single unrelated pre-existing Batch 6 test during a backgrounded run was reproduced as passing cleanly in isolation and on a subsequent full fresh run - not a Batch 7 regression, see §29) |
+| `git diff --check` | **PASS** — no whitespace errors |
+
+## 29. A note on browser-test flakiness during this batch's validation
+
+One `npm run test:browser` invocation, run in the background while many Chrome processes were already active on the machine, reported 19 failed tests across 11 files - all in pre-existing v0.1-v0.3-era suites (e.g. `windowScrollScenario.test.ts`) this batch never touched, all failing with a 30s timeout, and the run itself took ~8x longer than normal (394s vs. ~50-115s). This is a resource-contention symptom, not a functional regression: the exact same failing test file was re-run in isolation immediately afterward and passed cleanly, and a subsequent full fresh `npm run test:browser` run passed all 168/168 tests. No source change was made in response to this - it was correctly diagnosed as environmental, not a defect.
+
+## 30. Built viewer smoke
+
+Fixture: real before/after observations, comparison, contract evaluation (genuine `overallVerdict: "FAIL"`), approved reference (genuine fidelity PASS), and a real `BoundedAgentContextArtifact` (adequate, one `correlated` target, fidelity `pass`) built via `.my-dev-kit-workflow\v0.8\batch-07\tmp\build-smoke-context.mjs` (not committed) against the compiled `dist/*.js`, written to `.my-dev-kit-workflow\v0.8\batch-07\contexts\smoke-context.json`.
+
+Command: `node dist/cli.js view --root "<root>" --context-file "<context.json>" --bindings-file "<bindings.json>" --port 4319 --no-open`
+
+All required checks passed against the real running built server: `/api/status` → `200`; `/api/index` → 8 real records; `/api/context` → `status:"valid"`, `adequacy:"adequate"`, `correlations[0].status:"correlated"`, `fidelity.state:"pass"`, and every `sourceResolution` field `resolved` (2 observations, comparison, evaluation, reference); write method → `405`; PWA shell → `200`; `sw.js` contains zero `api/context` occurrences; the coexisting live fidelity endpoint (`--bindings-file` also supplied) independently returns a real `state:"pass"` for the same reference/candidate, proving `--bindings-file`/`--context-file` coexistence; a directory-traversal probe against `/api/artifacts/<handle>` returned `404` (no filesystem escape); the evidence root contained exactly the 10 expected real fixture files with no stray writes; the context JSON file's checksum was confirmed unchanged after the server session; `netstat` confirmed `127.0.0.1:4319` only; the server was located by its real PID and terminated with `taskkill /F`; a follow-up `netstat` confirmed the port was released.
+
+**Result: PASS.**
+
+## 31. Generated path inventory
+
+| Path | Disposition |
+|---|---|
+| `WORKFLOW_ROOT\tmp\build-smoke-context.mjs` | Retained (dev tooling, not committed) |
+| `WORKFLOW_ROOT\contexts\smoke-context.json` | Retained (dev tooling, not committed) |
+| `WORKFLOW_ROOT\bindings\smoke-bindings.json` | Retained (dev tooling, not committed) |
+| `WORKFLOW_ROOT\smoke\evidence-root` | Retained - 10 real fixture files verified |
+| `WORKFLOW_ROOT\logs\*` | Retained (smoke evidence) |
+| `WORKFLOW_ROOT\my-dev-kit-index\*` | Retained |
+| `WORKFLOW_ROOT\{cache,fixtures}` | Retained, empty/unused |
+| Repo-root `dist/` | Ordinary build output (gitignored) |
+| Sibling `...my-frontend-observer.my-dev-kit-workflow\v0.8\{batch-01,02,03}` | Untouched |
+| Inside-repo `.my-dev-kit-workflow\v0.8\{batch-04,05,06}` | Untouched |
+
+## 32. Repository pollution check
+
+**PASS.** `git status --short` before staging showed exactly the 10 modified + 8 new Batch-7-owned paths listed in §25/§26. No unexpected file/directory anywhere in the repository or its parent. No malformed sibling Batch 7 workflow path exists.
+
+## 33. Batch 1-6 regression check
+
+**PASS.** All 168 browser tests across 17 files pass on a clean run, including every Batch 1-6 test file, unmodified except the three additive test-file changes described in §26 (`cliView.test.ts`/`cliViewDispatch.test.ts` for the new `--context-file` flag, `viewerPwaBuild.test.ts` for the new cache-boundary assertion) - no pre-existing assertion was weakened or removed.
+
+## 34. v0.1-v0.7 regression check
+
+**PASS.** Full unit suite (1156/1156) green; `src/domain/boundedAgentContext*.ts` and every existing reader/service are byte-for-byte unchanged except the two additive exports already documented in Batch 6 (`deriveCoordinateScale`) - Batch 7 touches zero files under `src/domain/`.
+
+## 35. Deviations
+
+- The same recurring `$WORKFLOW_ROOT` path-instruction contradiction as every prior batch since Batch 4, resolved identically (§2).
+- No other deviation from the task's literal text.
+
+## 36. Remaining uncovered risks
+
+- **Task §65 Case K (multiple source observations relevant to the same target) has no dedicated real-browser fixture/test** this batch, though the implementing code (`SourceObservationTargetCheck`, §22) structurally lists every match rather than picking one, by construction - a real-browser proof for this specific case is a reasonable follow-up.
+- **`resolveContextSources` performs up to six independent bounded evidence-tree walks per `/api/context` request** (one per source-reference kind, run in parallel) - the same per-request-recomputation-cost category already noted as a residual risk in the Batch 4/5/6 reports for linked-evidence resolution generally. Not a correctness risk.
+- **The context/evidence mode toggle in `App.tsx` is a simple two-state switch, not integrated with the URL/history** - navigating away and back within a session loses the "which mode was active" state on a full page reload (not persisted, by design - session-only). A minor UX limitation, not a correctness concern.
+- Batches 1-6's previously reported risks (install-prompt "available" branch untested in headless Chromium, no live service-worker execution test, per-request linked-evidence walk cost, lock's zoom-multiplier mirroring simplification) remain unresolved and out of this batch's scope.
+
+## 37. Out-of-scope confirmation
+
+Confirmed absent from this batch's diff: bounded-agent-context persistence/writer, running my-dev-kit from the viewer, inventing static/source ownership, rebuilding bounded-agent-context at runtime, rebuilding runtime/static correlation at runtime, arbitrary filesystem browsing, source-code file browsing, raw evidence editing, annotation, source editing, automatic correction, cloud hosting, database, authentication, collaboration.
+
+## 38. Final verdict
+
+Batch 7 ("Bounded agent context, correlation, provenance, and raw evidence navigation") is implemented and independently validated: a developer can launch `view --context-file` with one explicit, validated `BoundedAgentContextArtifact`, inspect its identity/profile/adequacy/reasons, every bounded runtime target's included-or-honestly-absent fields, required-vs-optional omissions and truncations with required loss made visually unmistakable, runtime/static correlation exactly as `correlated`/`ambiguous`/`unavailable` (or honestly "not included" when the field itself is absent) with every ambiguous candidate shown and none promoted as a winner, static producer/candidate identities displayed verbatim and never treated as filesystem paths or edit authorization, and a bounded reference-fidelity projection (mismatches, protected context, blocked state) displayed alongside - never merged into - a separately-triggered live Batch 6 fidelity evaluation reusing that exact unmodified component - while every exactly-resolved Observer source reference safely navigates to its existing Batch 2/3/4/5 raw-evidence and visual-workspace surfaces, entirely within the authorized evidence root. The viewer never runs my-dev-kit, never calls `projectBoundedAgentContext`, and never calls `deriveRuntimeStaticCorrelations`/`attachRuntimeStaticCorrelations` at runtime (all three grep-confirmed). No Batch 8 release/integrated-hardening work was pulled forward, and no release/publication action was taken. Package version remains `0.7.0`.