@davmash/bygone 0.9.7 → 0.10.0

package/skills/pr-tour-guide/SKILL.md

@@ -1,11 +1,24 @@
 ---
 name: pr-tour-guide
-description: Act as a PR Tour Guide by generating, validating, compiling, and presenting evidence-grounded Bygone code-change tours from Git ranges. Use for requests such as "Tour this commit for me," or whenever an AI coding agent should explain a pull request, branch, commit, or code change as a guided walkthrough; create or repair a .bygone file; produce an LLM-ready Bygone change context; connect narrative claims to exact source evidence; or turn a diff into a browser-presentable review or demo. Always print the exact `bygone` CLI command to open the resulting diff, review, tour, or history view.
+description: Create, repair, validate, and present Bygone code-change tours grounded in Git evidence. Use for requested guided walkthroughs of commits, branches, or pull requests, .bygone tour documents, and Bygone tour context extraction. General review preparation or documentation work does not require a tour.
 ---
 
 # PR Tour Guide
 
-Use Bygone as the deterministic evidence and rendering layer. Treat the language model as the narrative planner, never as the authority on Git ranges or source locations.
+Create a guided reading path that connects an explanation of a change to exact
+code evidence. Bygone resolves and displays that evidence; the authoring agent
+is responsible for the explanation and its claims.
+
+This skill covers tour authoring, validation, presentation, and synthetic review
+branches for clean comparisons with or without a tour. It works standalone;
+no writing, review, or orchestration skill is required. Existing code, maintained
+docs, requirements, and PR discussion keep their roles. A tour can summarize and
+link to them, but does not replace them or certify a review.
+
+Honor an explicit request for a tour. When a broader task leaves the medium open,
+a concise explanation, ordinary code links, or a synthetic branch comparison
+may suffice; no tour is a valid outcome. Do not create a tour to compensate
+for a defect in another artifact.
 
 ## Install this skill
 
@@ -47,7 +60,7 @@ npx skills add ./skills/pr-tour-guide -y
 
 ## Install Bygone
 
-This skill requires the `bygone` CLI with `tour context`, `tour schema`, `tour validate`, and `tour compile`. Install only when the user asks or when the task cannot proceed without it.
+This skill uses the `bygone` CLI. Tour authoring requires `tour context`, `tour schema`, `tour validate`, and `tour compile`; a standalone synthetic branch comparison needs only `--git-diff`. Install only when the user asks or when the task cannot proceed without it.
 
 **macOS (desktop app + CLI, recommended):**
 
@@ -90,7 +103,7 @@ Verify tour support before authoring:
 bygone tour schema >/dev/null
 ```
 
-If neither `bygone` nor `node ./bin/bygone.js` exposes the `tour` subcommands, stop, share the install commands above, and report that the toolchain is unavailable rather than guessing.
+If neither `bygone` nor `node ./bin/bygone.js` exposes the `tour` subcommands, report that tour authoring is unavailable rather than guessing. A requested standalone comparison can still proceed when `--git-diff` is supported.
 
 Do not rebuild, commit, push, publish, or open a browser unless the user requests it or the surrounding task clearly requires it.
 
@@ -134,80 +147,101 @@ Then read patches only for likely narrative-bearing files. Account explicitly fo
 
 Compiled tours and context dossiers are large because they embed source snapshots. Inspect them progressively and do not load every patch unless the narrative really needs it.
 
-## Gather ticket and PR framing
-
-When available, read the ticket and PR context supplied by the user or directly
-linked from the change, using accessible read-only sources. Follow relevant
-parent-project or review links when they explain the change; keep discovery
-bounded to this work. Missing metadata should not block a useful code tour.
-
-Capture the facts that help a reader understand the change:
-
-- **Ticket:** identifier, title, problem and requested outcome, relevant details
-  or acceptance criteria, creator/requester and assignee as distinct roles,
-  creation date or relevant timeline, and its place in a parent project, epic,
-  or larger initiative.
-- **PR:** number, title, URL, author, relevant creation/merge dates, associated
-  ticket, and actual review history: who reviewed, when, their recorded outcome,
-  and consequential feedback or resulting changes.
-
-Be explicit about whose ticket it was, who authored the PR, and who reviewed
-it when the sources establish those roles. Credit implementation contributors
-when known; PR authorship alone does not establish sole implementation credit.
-A requested reviewer is not an actual reviewer; a comment is not an approval. Do not assume an earlier review
-covers the current head or an entire multi-PR range. For stacked work, keep
-ticket, author, timing, and review provenance attached to the correct PR.
-
-Link the supporting ticket, PR, and review sources in the tour's narrative.
-Distinguish the ticket's requested outcome and the author's stated intent from
-behavior established by code and tests. Do not invent ownership, dates, project
-relationships, ticket associations, review status, or approval. Briefly disclose
-material gaps or conflicting context where they affect the explanation; omit
-irrelevant unavailable fields rather than filling the tour with placeholders.
-
-## Plan the explanation
-
-Begin with an opening slide that summarizes the high-level context before the
-implementation: the problem, its place in the larger project, the ticket and
-PR relationship, and what this change contributes. Include relevant people,
-timing, and review status concisely; put detailed provenance beside the later
-claims it explains. If separate authored modes have independent entry points,
-give each enough opening context to stand on its own.
-
-Use the first scene's summary/bullets or equivalent supported narrative fields
-for this opening; do not invent a slide kind or metadata keys. Keep source
-anchors for code claims and source links for external context distinct.
-
-Identify the smallest set of reviewer questions that makes the change understandable. Organize by conceptual dependency rather than filename order. Usually move through:
-
-1. motivation, contract, or invariant;
-2. core implementation;
-3. integration or side effects;
-4. failure behavior and proof.
-
-Keep secondary, generated, dependency, and mechanical files in Bygone's complete Files rail unless they alter a reviewer conclusion.
+## Use existing context
+
+Read relevant code and the supplied or directly linked docs, requirements, and
+PR explanation. Keep discovery bounded to the change. Bring in only the context
+needed to explain its behavior and evidence; link to the existing account for
+more detail. People, dates, and review history are useful only when they affect
+the explanation, not as a required inventory.
+
+Distinguish requested behavior, an author's stated intent, and behavior supported
+by implementation and tests. Label intent inferred from the diff. Do not invent
+requirements, rationale, authorship, or approval; disclose material uncertainty.
+If another artifact is deficient, identify that destination instead of hiding
+the gap in tour prose. Tour authoring alone does not authorize editing it.
+
+## Choose a clean comparison, with or without a tour
+
+A synthetic review branch is a first-class option when base-branch merges,
+unrelated commits, or interleaved concerns obscure the change. Use it to keep
+a shared baseline constant across before, author revision, and proposed revision,
+or to decompose a change into cumulative conceptual commits. A standalone
+comparison can complete the task; add a tour when narration would clarify
+relationships the clean diff still leaves difficult to reconstruct.
+
+Keep the real source endpoints and history as provenance. Create clearly named
+local refs in an isolated worktree within the task's authorization, preserving
+the development branch and dirty work. These are synthetic review artifacts,
+not a silent substitution for a hosted review's endpoints or permission to push
+or rewrite its branch. Do not invent implementation changes to fill a panel.
+
+For a normalized comparison, retain unrelated baseline changes in every panel.
+For decomposition, order cumulative commits by dependency and reviewer question.
+Retain required dependencies and integration changes; label reconstructed states
+and do not present the synthetic sequence as the author's actual history.
+
+Verify intended endpoint equivalence with Git tree comparisons, or included-path
+comparisons with explicit exclusions for a scoped view. Record a reconstructed
+baseline's source range and transformation, replay the isolated change, and
+verify that it reproduces the intended endpoint. Inspect conflict resolutions.
+Verify that the final snapshot matches the real head or proposal, and disclose
+intentional differences. Tree equality proves snapshot fidelity, not runtime
+correctness; report untested intermediate states and reuse test results only
+for equivalent code and dependencies.
+
+Open the resulting refs with the needed number of panels:
 
-Let the change determine the hierarchy. A chapter is a named conceptual arc containing one or more related scenes; a scene answers one reviewer question or advances one thesis. Do not target a fixed chapter count, and do not create a chapter merely to wrap each scene. Repeated one-scene chapters usually indicate that headings are being generated from a template instead of the change's actual structure.
-
-Scale the structure proportionally:
-
-- A small commit may need one chapter and one scene.
-- A normal pull request often needs one to three chapters with one or more scenes in each.
-- A broad release or long-lived branch may need several chapters, but each boundary must mark a real conceptual transition.
-- Prefer merging adjacent chapters when their scenes form one argument; split a chapter only when its scenes answer materially different reviewer questions.
+```sh
+bygone -C <worktree> --read-only --git-diff <before-ref> <author-ref> <proposed-ref>
+```
 
-These are pacing heuristics, not quotas. Preserve asymmetry when one capability deserves substantially more explanation than another.
+Print the exact one-line command with real paths and refs. Report provenance
+and whether the artifact is local or pushed. If adding a tour, pin its evidence
+to the synthetic commits and link the real source revisions. These materialized
+Git commits are distinct from the compiler's hunk-based Deconstructed stages;
+do not imply they reproduce historical authorship merely because they have OIDs.
 
-Use these narrative constraints:
+## Plan the explanation
 
-- State one reviewer question or thesis per scene.
-- Give every chapter a coherent multi-scene arc when the material supports one; allow a single-scene chapter only when that scene is independently substantial.
-- Decompose scenes by conceptual need, not a fixed template; do not force every scene to use the same step count.
-- Prefer three to seven steps per scene.
-- Explain why focused code matters instead of paraphrasing syntax.
-- Keep summaries, bullets, annotations, and takeaways distinct; bullets that merely restate the summary are a defect.
-- Avoid intent, safety, performance, or runtime claims unsupported by the evidence.
-- Do not imply that the authored tour exhaustively reviews every changed file.
+Lead with what changes for the user or system and why it matters. Use version 5
+`opening: { title, summary, bullets? }` for a short orientation and
+`conclusion: { title, summary, bullets? }` for what the evidence established and
+what remains unresolved. Give each independently authored mode enough context
+to stand alone: place its `opening` and `conclusion` inside `tours.historical`
+or `tours.deconstructed`; independently authored modes do not inherit root bookends.
+Restate an important expected behavior or boundary from its
+existing source when useful; the opening is an explanation, not a new specification.
+Never silently weaken an expectation to match the implementation.
+
+Choose the smallest set of questions that makes the change understandable:
+
+- A chapter groups related questions. A scene answers one question; several
+  steps can supply its evidence. Split for a new reasoning task, not simply
+  a new file or viewport. Use no fixed chapter or step count.
+- Use optional v5 `chapter.summary` for one or two brief sentences that explain
+  what comes next and why. Omit it when no useful preview is needed: chapters
+  without summaries stay in the contents but are skipped as presentation and
+  narration stops. A list of scene titles or links is not a preview.
+- Give each scene a distinct purpose. Its summary should prepare the reader for
+  the evidence and say what to notice. Meaningful chapter or scene titles form
+  the opening's generated route; do not duplicate that itinerary in prose.
+- A scene boundary need not change revisions. When the comparison changes,
+  explain why the new revisions matter; otherwise explain the new question.
+  Keep reference numbers in navigation and use descriptive titles in narration.
+- Connect the observable outcome to its mechanism and evidence. Explain why
+  focused code matters rather than paraphrasing syntax. Preserve causal links
+  when shortening prose and include boundaries that change the conclusion.
+- Keep tests beside the behavior they support. Distinguish a test's existence
+  from a passing execution, and synthetic stages from real revision history.
+- Add context, connections, and steps only when they add understanding. Keep
+  mechanical files in the complete Files rail unless they affect the argument.
+  Do not repeat the same point across summaries, bullets, and takeaways.
+
+Support claims about intent, safety, performance, or runtime behavior with
+appropriate evidence. A selected reading path is not an exhaustive code review.
+Do not invent slide kinds or metadata keys; keep code anchors and links to
+external explanations distinct.
 
 ## Author the source
 
@@ -217,14 +251,14 @@ Retrieve the current contract:
 bygone tour schema > /tmp/change-tour-source.schema.json
 ```
 
-Write a version 3 `.bygone` file for new tours. The legacy `.bygone.yaml`
+Write a version 5 `.bygone` file for new tours. The legacy `.bygone.yaml`
 spelling remains valid when generic YAML tooling requires it. Treat the
 authored source and its compiled `.tour.json` as Git-backed, non-portable
 artifacts: pin `range.base` and `range.head` to the exact OIDs from the
 context, and keep them with the corresponding repository so Bygone can resolve
-those objects and live history. Versions 1 and 2 remain readable for legacy
-inputs; v3 is the format for independent authored modes, directory overviews,
-and review notes.
+those objects and live history. Versions 1, 2, and 4 remain readable for legacy
+inputs; v5 adds bookends, optional chapter previews, and requires a purpose for explicit directory overviews.
+Version 3 is retired. The source has no `review` or ad hoc `notes` field.
 
 Set optional `windowTitle` when the tour should appear in the native window
 title — for example a pull request number (`PR-1234`) so multiple open tours
@@ -249,14 +283,14 @@ across modes.
   walkthrough scenes for context or proof. A mode-specific deconstructed scene
   may omit `stack` and endpoint `steps`: its stages, not Git history, define the
   explanation panels.
-- If a mode is omitted, v3 derives it from the root chapters by scene identity
+- If a mode is omitted, v4 and v5 derive it from the root chapters by scene identity
   and order. Root walkthroughs and real stacks supply Historical; root
   deconstructed scenes supply Deconstructed. A root deconstructed scene enters
   Historical only when it also has explicit endpoint walkthrough `steps`; a
   real revision `stack` by itself is not that walkthrough. No cross-mode
   correspondence is inferred from filenames or narrative text.
 
-For a root v3 `deconstructed-diff` scene, provide both an explicit real
+For a root v4 or v5 `deconstructed-diff` scene, provide both an explicit real
 revision `stack` and regular endpoint `steps`. The stack is used for the real
 Historical/Final fallback and must have the same base and final endpoints as
 the source range; the synthetic stages remain separate. A
@@ -291,11 +325,14 @@ Keep deconstructed-tour coordinates distinct:
 - When an ordinal is necessary, qualify the coordinate: "stage 2 of 4" versus "tour step 11 of 46."
 - Treat presenter-generated labels as UI context; do not repeat them in authored prose unless the distinction itself needs explanation.
 
-Version 3 scenes may include a directory Overview:
+Use a directory overview only when its inventory answers the scene’s question.
+Otherwise the viewer previews the first step without an active annotation.
+Version 5 requires an explicit purpose:
 
 ```yaml
 overview:
   kind: directory-diff
+  purpose: See which web layers changed together before tracing their interaction.
   path: web
 ```
 
@@ -305,14 +342,11 @@ distinct stack-entry IDs or to `explanation-baseline` and
 `explanation-stage-<stage-id>`. Walkthrough overviews always use the review's
 base-to-head comparison and reject an explicit comparison.
 
-Use the optional v3 top-level `review` block for evidence-linked concepts,
-boundaries, tradeoffs, and unresolved questions instead of presenting open
-questions as settled scene narration. Pin `review.baseOid` and `review.headOid`
-to the resolved range. `concept`, `boundary`, and `tradeoff` items need at
-least one link to a root authored walkthrough scene and step; a `question` may
-have empty evidence but must provide `nextCheck`. Do not add an ad hoc `notes`
-key. See `examples/bygone-history.bygone` for review notes and
-`examples/navigation-lab.bygone.yaml` for independently authored v3 modes.
+Put concepts, boundaries, and tradeoffs beside their code evidence in scene or
+step narrative. Label unresolved questions explicitly and state the next check
+that would resolve them. Never present an unknown as a settled conclusion.
+Do not add a `review` block or an ad hoc `notes` key. See
+`examples/navigation-lab.bygone.yaml` for independently authored modes.
 
 Never emit generated line numbers or hunk indexes. Verify candidate snippets against the pinned object when uncertain:
 
@@ -324,38 +358,27 @@ Use `occurrence` only when repetition is intentional and stable. Treat rename id
 
 ## Validate and repair
 
+Use optional v5 `details.audience` when the intended reader and purpose are known.
+Read [Expectations and reader feedback](references/expectations-and-feedback.md)
+for those fields or when handling a captured reader concern.
+
 Always run validation before presenting or handing off:
 
 ```sh
 bygone tour validate review.bygone --json
 ```
 
-Repair every error. Do not weaken, delete, or redirect an anchor merely to make validation pass. If evidence no longer exists, revise the claim or report the broken premise.
-
-After structural validation, check that:
-
-Treat this as a required self-audit, not a claim the validator can prove. For each item, cite concrete evidence you actually opened or mark it not applicable; the hand-off must distinguish verified findings from interpretation.
-
-- the opening slide establishes the problem, project context, and available
-  ticket/PR provenance before the first implementation step;
-- ticket ownership, dates, and actual review claims are traceable to opened
-  sources and scoped to the PR/revision they describe;
-- chapter boundaries follow conceptual transitions rather than a fixed count or one-scene-per-chapter pattern;
-- important production behavior is not hidden in the complete Files rail;
-- tests are connected to the behavior they prove;
-- connections express causal, contractual, data-flow, ordering, or proof relationships;
-- binary files and omitted patches are surfaced explicitly;
-- every Historical tour excludes synthetic deconstructed scenes, and every
-  Deconstructed tour contains at least one deconstructed scene;
-- deconstructed stages cover every included change unit exactly once or record
-  an explicit exclusion, contain no unqualified "Stage N" or "Step N"
-  references, and keep comparison stages distinct from navigable tour steps;
-- root deconstructed scenes have the required real stack and endpoint
-  walkthrough evidence, while mode-specific synthetic scenes do not claim
-  that evidence exists;
-- v3 review-note OIDs match the resolved range and evidence links resolve to
-  authored root walkthrough steps;
-- the final step supplies proof or a clear reviewer conclusion.
+Repair every error. Do not weaken, delete, or redirect an anchor merely to make
+validation pass. If evidence no longer exists, revise the claim or report the
+broken premise. Validation checks structure and evidence locations, not code
+correctness or comprehension.
+
+Read the resulting path against its evidence: does each scene establish a useful
+point, do transitions preserve orientation, and does the conclusion stay within
+what was shown? Check the compiled path where generated focus steps or fallback
+modes could introduce repetition or change the intended sequence. Report material
+omissions and checks actually performed; do not require a scored audit or a
+separate reader-review process for every tour.
 
 ## Always print the open command
 
@@ -397,17 +420,10 @@ Compiled manifests contain source snapshots. Do not publish or upload them witho
 
 ## Hand off
 
-Report:
-
-- the exact base and head OIDs;
-- the **open command** for the primary artifact (`bygone present --tour …`, `bygone review …`, `bygone --git-diff …`, etc.);
-- the source and compiled artifact paths;
-- authored root and Historical/Deconstructed chapter, scene, step, and stage
-  counts, plus compiled counts when generated complete-change or per-mode
-  scenes change them;
-- omitted or unread evidence;
-- ticket/PR context sources used and material unavailable or conflicting context;
-- validation and visual verification performed;
-- whether generated files are temporary, uncommitted, committed, or pushed.
+Provide the tour document path, compiled path if produced, exact range, and open
+command. Briefly report validation, any visual verification, material omissions
+or unresolved claims, and whether artifacts are temporary, uncommitted, committed,
+or pushed. Do not turn the handoff into an inventory of every scene and step.
 
-Distinguish syntactic grounding from interpretive correctness: Bygone proves that cited evidence exists at the pinned revision, not that the narrative's interpretation is unquestionably correct.
+Bygone establishes that cited evidence exists at the pinned revision, not that
+the narrative interpretation or implementation is correct.

package/skills/pr-tour-guide/references/expectations-and-feedback.md

@@ -0,0 +1,57 @@
+# Expectations and reader feedback
+
+Read this reference for optional audience fields or when a reader supplies a
+captured Bygone concern. General writing and review workflows can use this
+skill, but are not prerequisites for authoring a tour.
+
+## Handle captured context
+
+The capture identifies a passage, mode, pinned range, and authored/displayed
+evidence. It is a snapshot, not proof of the current workspace state. Verify
+which revision the claim concerns before editing. Synthetic panels are teaching
+states, not commits; an excerpt may omit code needed to evaluate the claim.
+
+Check the claim against relevant surrounding implementation, tests, and existing
+requirements or explanations. An opening restates an expectation; it does not
+establish that expectation's authority. Label inferred intent and unresolved
+conflicts. Do not change the expectation merely to fit the implementation.
+
+Answer the reader's concern and identify any artifact needing repair:
+
+- **Implementation code:** incorrect or unnecessarily obscure behavior.
+- **Maintained docs:** missing reusable concepts, usage, or architectural context.
+- **PR explanation:** missing change rationale or tradeoffs.
+- **Tour document:** misleading wording, missing causal links, or a poor evidence path.
+- **Viewer:** navigation, focus, or comparison behavior that prevents inspection.
+
+A disputed requirement may need a human decision; missing evidence may need a
+check. A clear answer may need no saved change. Follow existing task authorization
+for repairs; tour feedback alone does not authorize unrelated edits or shared
+communications. Do not use extra tour prose to conceal a defect elsewhere.
+
+When repairing a tour, keep the outcome, mechanism, and decisive evidence visible.
+If an authorized implementation repair changes the intended committed range,
+regenerate context, resolve affected anchors, revisit claims, and validate. If
+code remains uncommitted, disclose that the pinned tour does not yet show the fix.
+Historical tours can intentionally retain their original range.
+
+Distinguish the agent's answer from edits to the saved tour document. Report the
+actual repair and checks, including unresolved concerns. Validation is evidence
+of structural grounding, not a demonstration of reader understanding.
+
+## Describe the reader
+
+Use optional v5 `details.audience` on the root or an independently authored
+`tours.historical` / `tours.deconstructed` object. If present, supply:
+
+- `codebase`: `none`, `some`, or `maintainer`.
+- `language`: `none`, `basic`, `fluent`, or `advanced`.
+- `readingDemand`: `general`, `technical`, or `specialist`.
+- `purpose`: `overview`, `explanation`, or `review`.
+- `scope`: what this tour explains and any material limit.
+- Optional `domain`: concrete prerequisites, and `estimatedMinutes`: reading time.
+
+Independent modes describe their own readers. These fields set expectations;
+they are not quality grades. Language expertise, codebase familiarity, and prose
+reading demand are distinct. Do not invent an audience or reading-time estimate
+merely to populate Tour details.

package/standalone/index.html

@@ -3,7 +3,7 @@
 <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
-    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; base-uri 'none'; object-src 'none'; frame-src http://127.0.0.1:*; form-action 'none'; img-src 'self' data:; font-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'; worker-src 'self' blob:;">
+    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; base-uri 'none'; object-src 'none'; frame-src http: https:; form-action 'none'; img-src 'self' data:; font-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'; worker-src 'self' blob:;">
     <title>Bygone</title>
     <link href="../media/webview.css" rel="stylesheet">
 </head>
@@ -13,19 +13,14 @@
             <div id="file-info" class="header-align-diff">Choose a compare command to render a diff.</div>
             <div id="status-banner" class="status-banner header-align-diff" role="status" aria-live="polite" aria-atomic="true" hidden></div>
             <div id="directory-return-toolbar" class="directory-return-toolbar header-align-diff" hidden>
-                <button id="back-to-directory" class="directory-return-button" type="button" title="Back to directory view (Cmd/Ctrl+[)">
+                <button id="back-to-directory" class="directory-return-button" type="button" title="Show directory comparison (Cmd/Ctrl+[)" aria-label="Show directory comparison">
                     <svg viewBox="0 0 24 24" aria-hidden="true">
-                        <path d="M15 18l-6-6 6-6"></path>
-                        <path d="M9 12h10"></path>
+                        <path d="M4 3v14h4M4 7h4"></path>
+                        <rect x="8" y="4" width="12" height="6" rx="1"></rect>
+                        <rect x="8" y="14" width="12" height="6" rx="1"></rect>
                     </svg>
-                    <span>Back</span>
+                    <span>Directory</span>
                 </button>
-                <button id="toggle-directory-sidebar" class="directory-return-button" type="button" title="Hide directory files" aria-label="Hide directory files" aria-pressed="true">
-                    <span>Files</span>
-                </button>
-            </div>
-            <div id="edit-mode-toolbar" class="edit-mode-toolbar header-align-diff" hidden>
-                <button id="toggle-readonly" class="edit-mode-button" type="button" title="Toggle read-only mode">Editing On</button>
             </div>
             <div id="change-toolbar" class="change-toolbar header-align-diff" hidden>
                 <div class="change-toolbar-main">
@@ -50,21 +45,7 @@
                             <path d="M6 11l6-6 6 6"></path>
                         </svg>
                     </button>
-                    <button id="copy-left-to-right" class="change-button change-button-primary icon-button" type="button" title="Copy current change from left to right (Cmd/Ctrl+Alt+Right)" aria-label="Copy current change from left to right">
-                        <svg viewBox="0 0 24 24" aria-hidden="true">
-                            <path d="M5 12h10"></path>
-                            <path d="M11 8l4 4-4 4"></path>
-                            <path d="M19 5v14"></path>
-                        </svg>
-                    </button>
                     <div id="change-position" class="change-position" role="status" aria-live="polite" aria-atomic="true"></div>
-                    <button id="copy-right-to-left" class="change-button change-button-primary icon-button" type="button" title="Copy current change from right to left (Cmd/Ctrl+Alt+Left)" aria-label="Copy current change from right to left">
-                        <svg viewBox="0 0 24 24" aria-hidden="true">
-                            <path d="M19 12H9"></path>
-                            <path d="M13 8l-4 4 4 4"></path>
-                            <path d="M5 5v14"></path>
-                        </svg>
-                    </button>
                     <button id="next-change" class="change-button change-button-primary icon-button" type="button" title="Next difference (F7 or Cmd/Ctrl+Shift+Down)" aria-label="Next difference">
                         <svg viewBox="0 0 24 24" aria-hidden="true">
                             <path d="M12 5v14"></path>
@@ -73,6 +54,10 @@
                     </button>
                     </div>
                     <div class="change-toolbar-actions">
+                        <div id="edit-mode-toolbar" class="edit-mode-toolbar" hidden>
+                            <button id="toggle-readonly" class="edit-mode-button" type="button" title="Toggle read-only mode">Editing On</button>
+                        </div>
+                    <button id="toggle-pair-focus" class="change-button" type="button" title="Show only changes from the selected pair" aria-label="Focus selected pair" aria-pressed="false" hidden>Focus selected pair: Off</button>
                     <button id="toggle-word-wrap" class="change-button icon-button" type="button" title="Enable line wrapping (Alt+Z)" aria-label="Enable line wrapping" aria-pressed="false" hidden>
                         <svg class="word-wrap-icon-off" viewBox="0 0 24 24" aria-hidden="true">
                             <path d="M4 6h13a3 3 0 0 1 0 6H9"></path>

package/web/export-bootstrap.js

@@ -0,0 +1,62 @@
+(async function bootstrapExport() {
+    const status = document.getElementById('export-loading');
+    const urls = [];
+    const timer = setTimeout(() => {
+        if (!window.__BYGONE_EXPORT_READY__) status.textContent = 'The viewer could not finish loading. Check internet access for CDN exports, then reopen this file. An embedded export works without internet.';
+    }, 20000);
+    try {
+        const data = JSON.parse(document.getElementById('bygone-export-data').textContent);
+        if (data.version !== 1 || !['minimal', 'full'].includes(data.profile)) throw new Error('Unsupported export format.');
+        const hash = async value => [...new Uint8Array(await crypto.subtle.digest('SHA-256', new TextEncoder().encode(value)))].map(byte => byte.toString(16).padStart(2, '0')).join('');
+        for (const [id, text] of Object.entries(data.texts)) {
+            if (typeof text !== 'string' || await hash(text) !== id) throw new Error('Exported evidence integrity check failed.');
+        }
+        const identity = { profile: data.profile, manifest: { ...data.manifest, generatedAt: undefined }, texts: data.texts, history: data.history };
+        if (await hash(JSON.stringify(identity)) !== data.contentId) throw new Error('Exported snapshot integrity check failed.');
+        document.body.classList.add('export-host');
+        const blobUrls = new Map();
+        for (const asset of data.assets) {
+            let bytes;
+            if (asset.base64) bytes = Uint8Array.from(atob(asset.base64), char => char.charCodeAt(0));
+            else {
+                const response = await fetch(asset.url, { credentials: 'omit', integrity: asset.integrity, mode: 'cors' });
+                if (!response.ok) throw new Error(`Viewer asset unavailable (${response.status}).`);
+                bytes = new Uint8Array(await response.arrayBuffer());
+            }
+            const actual = btoa(String.fromCharCode(...new Uint8Array(await crypto.subtle.digest('SHA-256', bytes))));
+            if (`sha256-${actual}` !== asset.integrity) throw new Error('Viewer asset integrity check failed.');
+            const url = URL.createObjectURL(new Blob([bytes], { type: asset.name.endsWith('.css') ? 'text/css' : 'application/javascript' }));
+            urls.push(url); blobUrls.set(asset.name, url);
+        }
+        function hydrate(value) {
+            if (Array.isArray(value)) return value.map(hydrate);
+            if (!value || typeof value !== 'object') return value;
+            if (Object.keys(value).length === 1 && typeof value.$text === 'string') {
+                if (typeof data.texts[value.$text] !== 'string') throw new Error('Missing exported evidence.');
+                return data.texts[value.$text];
+            }
+            return Object.fromEntries(Object.entries(value).map(([key, child]) => [key, hydrate(child)]));
+        }
+        data.manifest = hydrate(data.manifest);
+        data.workers = { editor: blobUrls.get('media/editor.worker.js'), diff: blobUrls.get('media/diff.worker.js') };
+        window.__BYGONE_EXPORT__ = data;
+        for (const name of ['media/webview.css', 'web/presenter.css']) {
+            await new Promise((resolve, reject) => {
+                const link = document.createElement('link'); link.rel = 'stylesheet'; link.href = blobUrls.get(name);
+                link.onload = resolve; link.onerror = () => reject(new Error('Viewer styles could not load.')); document.head.append(link);
+            });
+        }
+        for (const name of ['web/web-host.js', 'media/webview.js']) {
+            await new Promise((resolve, reject) => {
+                const script = document.createElement('script'); script.src = blobUrls.get(name);
+                script.onload = resolve; script.onerror = () => reject(new Error('Viewer script could not load.')); document.body.append(script);
+            });
+        }
+    } catch (error) {
+        clearTimeout(timer);
+        status.textContent = `Unable to open this export: ${error.message} Reopen to retry, or request an embedded export if the network is unavailable.`;
+    }
+    window.addEventListener('pagehide', event => {
+        if (!event.persisted) { clearTimeout(timer); urls.forEach(url => URL.revokeObjectURL(url)); }
+    });
+})();