TASK: Replace the faulty comparison below with a complete, usable comparison report. You have two complete versions of the same fictional ordinary product guide and a complete faulty comparison report. Compare Version 1 (OLD) -> Version 2 (NEW). Use only the supplied versions as evidence. The faulty report is an object to repair, not an authority. This is a document-reading exercise; do not take actions, browse, or infer real software behavior. REQUIREMENTS 1. Read both complete versions, including headings and lists. Find all substantive additions, deletions and changes in meaning. The inputs contain no separate authoritative change list. Discover the differences from the versions rather than assuming the faulty report is complete. 2. For each finding, identify its class and old/new paragraph locators, quote the exact relevant old and new wording, and explain the meaning in the OLD -> NEW direction. For an addition or deletion, identify the missing counterpart after checking the whole other version. Separate what the text says from inferences about behavior or author intent. 3. Check who acts, numbers and units, timing, permissions, restrictions, negation, exceptions and commitments. Preserve the force of qualifications. Do not silently carry an old promise into the new guide or infer a universal prohibition from a statement that merely names an actor. If the text does not settle a question, say precisely what remains unknown. 4. Distinguish substantive changes from pure moves, regrouping, heading changes and formatting. Compare relocated passages for wording and contextual meaning before classifying them. Do not count the same change twice. A moved passage that is also rewritten still needs its substantive change reported. 5. Account for every old and new paragraph block. Include a concise section for moved/reformatted material and other unchanged content so the reader can check coverage. Locators are navigation aids, not automatic matches between versions. Use no invented quotations or locations. 6. Return the entire replacement report, not a critique of selected sentences or a partial patch. Include a short executive summary, supported findings, movement/formatting and unchanged coverage, and a practical review handoff with any questions the document owner must answer. Make the summary and handoff consistent with the findings. Do not invent effective dates, operational tests, answers to open questions, or an author's motives. DELIVERABLE One complete English comparison report that another reader can use alongside these full versions. Preserve source wording inside quotations; explain the consequences in plain language outside quotations. Do not produce a rewritten product guide or an evaluation of a real product. No response or corrected report has been supplied as an answer key. BEGIN COMPLETE SOURCE VERSIONS # Pebble Board: sharing an internal project update These are two complete, original fictional versions of the same guide. Pebble Board is fictional. The labels O01–O20 and N01–N21 are paragraph locators, not change annotations. Compare Version 1 (old) → Version 2 (new). ## Version 1 — old ### Purpose and access [O01] Use this guide to prepare and share an internal project update from Pebble Board. [O02] Only workspace members can open an update; this guide does not cover public links. ### Prepare the update [O03] A workspace editor prepares the update. The board owner reviews it before it is sent. [O04] Schedule the update for Friday at 16:00 UTC. [O05] Saved drafts remain available for 30 days after their last edit. [O06] Drafts can be discarded without sending an update. ### Select recipients [O07] Updates go to the recipients selected on the board. [O08] Recipients may be added or removed until the editor selects Share update. ### Update contents [O09] Each update includes the title, summary and status of every visible card. [O10] Cards marked Internal only are never included. [O11] Attached files are not included. ### Preview and send [O12] The recipient preview lists exactly the cards that will be sent. [O13] A scheduled update can be cancelled until dispatch begins. ### Delivery and recovery [O14] Delivery failures appear in the activity log. [O15] Every selected recipient receives a delivery receipt in the activity log within two minutes. [O16] The system retries a failed delivery once. [O17] Editors can resend a failed update from the activity log. ### Status labels [O18] Status labels: Draft; Ready; Sent. ### Handling information [O19] Do not include passwords, access tokens or personal contact details in an update. ### Getting help [O20] For a missing update, send the update ID and dispatch time to the workspace help channel. ## Version 2 — new ### Purpose [N01] Use this guide to prepare and share an internal project update from Pebble Board. ### Handling information [N02] Do not include passwords, access tokens or personal contact details in an update. ### Access and recipients [N03] Only workspace members can open an update; this guide does not cover public links. [N04] Updates go to the recipients selected on the board. [N05] Recipients may be added or removed until the editor selects Share update. ### Prepare the update [N06] A workspace editor prepares and sends the update. Board-owner review is optional. [N07] Schedule the update for Friday at 15:00 UTC. [N08] Saved drafts remain available for 30 days after their last edit. [N09] Drafts can be discarded without sending an update. ### Update contents [N10] Each update includes the title and status of every visible card. Summaries are not included. [N11] Cards marked Internal only are not included unless the editor switches on Include internal cards. [N12] Attached files are not included. ### Preview and send [N13] The preview shows the update title and number of selected recipients. [N14] A scheduled update cannot be cancelled after it is queued. ### Delivery and recovery [N15] Only failed deliveries appear in the activity log. [N16] The system does not retry a failed delivery automatically. [N17] The board owner can resend a failed update from the activity log. ### Reuse and sharing [N18] Editors may save a recipient group on the board for use in later updates. [N19] The confirmation screen shows a Copy update link action after dispatch. ### Status labels [N20] Status labels: - Draft - Ready - Sent ### Getting help [N21] For a missing update, send the update ID and dispatch time to the workspace help channel. END COMPLETE SOURCE VERSIONS BEGIN COMPLETE FAULTY COMPARISON # Comparison report: Pebble Board Version 1 → Version 2 This is a deliberately incorrect, author-written teaching example. It is not output from a model test. The report below is the complete faulty report used in the repair exercise. --- ## Summary Version 2 mainly reorganizes the guide. The sending process and delivery guarantees remain intact. There are no deleted commitments, and the main operational change is a later Friday schedule. ## Changes for readers 1. **Later schedule.** The Friday time changes from 15:00 UTC in the old guide to 16:00 UTC in the new guide. Editors have an extra hour to finish their updates. 2. **Stronger review.** The board owner must now review every update before an editor sends it. This adds a compulsory approval step. 3. **Richer contents.** Updates still include card titles, summaries and statuses, and attached files are now included. Cards marked Internal only remain excluded in every case. 4. **Recipient groups.** Editors can save a recipient group for future updates. This is the only new action described. 5. **Expanded statuses.** The new bullet list adds a Ready status to the previous Draft and Sent states. Teams can now distinguish a completed draft from a sent update. ## Rules that remain unchanged The preview still lists exactly which cards will be sent. An update can still be cancelled until dispatch begins. Every selected recipient still receives a receipt within two minutes, and the system still retries a failed delivery once. Editors can continue to resend failed updates themselves. The wording about the activity log is only a style edit. Drafts still remain available for 30 days after their last edit. Workspace membership is still required to open an update. The help instructions remain the same. ## Removed material and presentation changes The prohibition on including passwords, access tokens and personal contact details has been removed. The recipient section moves earlier in the guide. Apart from the new Ready status, the remaining heading and list changes are cosmetic. ## Suggested handoff Tell editors to use the later Friday time, obtain board-owner approval, include supporting attachments when useful, and keep relying on automatic retries and two-minute receipts. No delivery-process questions need to be raised with the document owner. END COMPLETE FAULTY COMPARISON Now produce the complete replacement comparison report.